Real-time brute stack for R/V Langseth 
Due to Anthony Johnson's resignation, the realtime geom/UKOAA scheme can
not be implemented as described at the end of this document.

This scheme consists of three parts:
1)  Script init_seisnet, used to find the last shot written to the Seisnet raid.
2)  Script brute160 continuously reads the the list generated by init_seisnet, 
    reads the SEG-D file, processes it and creates a raster file for the 
    Atlantek 7225 plotter.
3)  Program versatec which continuously reads and plots new raster lines in the
    raster file generated in step 2.
    
Computer interconnectivity
Anthony Johnson's diagram
The Syntron acquistion system writes SEG-D shot files that are slightly modified by LDEO
and then written to the Seisnet program that write the shot to a multi-terabyte raid.
The raid is is NFS exported readonly to the computer named "proc1".  User 
"logadmin" is the only user allowed to access the seisnet raid.  The Seisnet
raid should not be exported to any other computer.

Sun computer "stacker" is the only computer with a SCSI connection required by the Atlantek
raster plotter.  SCSI is a very fast parallel connection and PCs and Macs don't have.
"proc1" and "stacker" share a disk via NFS (/data/working/CRUISEID)

Note:  The Atlantek plotter from the Ewing has been lost.  The old plotter was 
"nibs 7224".  The replacement plotter is "nibs 7225".  7224 plot files will be
garbage (stripes) when plotted on the 7225 plotter.  Use plotter parameter 
"plotter 7225" or "nibs 7225".

The "slight" LDEO modification to the SEG-D shot is the inclusion of the water
depth obtained from the multibeam system and the navigation from the PosNav
system.  If either the water depth or the navigation is missing, then the sioseis
brute stack will not work (plotting single shots is still viable though).

In spring 2011 the Linux sioseis executables were in /home/logadmin/bin and
the source were in /home/logadmin/src.  The latest sioseis may be downloaded as
per the main sioseis web page.

Script init_seisnet
bash init_seisnet script
csh init_seisnet script
Usage: init_seisnet seisnet_directory
Initialize the SIOSEIS-SEISNET interface
script init_seisnet lists the last two files in seisnet_directory every 5 seconds

Segddin stack parameter uses the second to last shot because the last shot might 
not be finished writing.

*******************        NEW TO SUMMER 2011      ***************************
If the Seisnet directory changes, kill the init_script and relaunch it with the
new seisnet_directory.  (Use the Unix ps command to find the pid and use it with
the Unix kill command).  Previously there was only one big directory that held
all shots, but in 2011 it appears that the shots are broken into REEL directories.
Shots will be lost if too much time elapses with "reel" changes.

????????        QUESTION       ????????    (Anthony or JD would know)   
If the SEG-D shots are in "REEL" directories, segddin stack could be modified so 
that the directory name is incremented by one when no new shots occur.  
e.g. directory REEL0001 becomes REEL0002.  The directory change would only happen 
if the new directory exists - this logic may be needed because I don't know if 
new shots are created during a mammal shutdown.
*************************************************************************

It is possible to start init_seisnet only once at the beginning of shooting.

init_seisnet may be run in background  ( & on the init_seisnet command or
control-z followed by the Unix bg command).   On my pc/cygwin machine the ps
command did not show init_seisnet as a pid, but it did show the sleep command
within the script.  Sleep is the child process of init_seisnet;  init_seisnet
is the parent process id or PPID, so I used the PPID in the kill command.

The list of two most recent shots is /tmp/latest and may be read by all users
on the same computer that the init_seisnet script runs on, thus multiple processes
may read the data simultaneously.  e.g. plot single shots in one window while the 
brute stack runs in a different window.

Brute stack scripts
A stack is a "brute" stack when an assumed velocity is used rather than one
derived through velocity analysis.  Graham Kent invented a method of varying
the NMO velocities based on the water depth rather than the normal variation
by RP/CMP number.  (see NMO parameter vtrkwb (velocity tracking water bottom).

There are several brute stacks scripts floating around, each based on the
a unique shooting geometry.  These scripts require quite a bit of geophysical
terminology and knowledge (e.g. channel sets and streamer geometry)

Script brute is intended to be general, but requires more script command arguments.
This script only uses the 160 traces closest to the source (2km) so that 
poor velocity estimates don't affect the stack quite as much as well as
requiring less computer resources.

Bash script brute160 was created for a 2km streamer
with 160 channels on one streamer (Coakley 2011).  (The sonobuoy is assumed to be
channel set 2 and is ignored in brute stack.  The near hydrophone is assumed
to be trace 160 and at 250m.)
Usage: brute160 line-name plot-direction(ltr/rtl)
e.g.    brute160  line01 rtl

Csh script brute468 was used for a 4km streamer 3-D
project.

In all "brute" scripts, the most recent shot is read using the init_seisnet script
and the segddin "stack" parameter.  The sioseis procs command is:
procs segddin prout geom wbt gather nmo stack diskoa avenor filter plot end
which indicates the traces be sorted or gathered into RP/CMP bins, moved-out,
stacked, filtered, gained, and an Atlantek raster plot created.

All these scripts use a velocity function that spatially varies according to water
depth.  *******    The velocity function should be modified for each cruise.  *******
Using the existing velocity function will work, and is better than using a 
constant velocity of water, the stack will be better the better the velocity 
function estimate.



Update of information presented further down this page.
MGL1106 provided my first multi-streamer UKOOA file.  Relating the multi-streamer
UKOOA file to the multi-streamer SEG-D file required a modification to segddin
parameter retrac.

The UKOOA file does not differentiate between streamers.  It simply numbers
the traces consecutively.  e.g. with 468 traces on each of four streamers, the
UKOOA file contained trace 468-1, 936-469, 1404-937, 1872-1405

The SEG-D file contains a channel set for each streamer and each channel set 
starts with trace (channel) number 1.

Therefore, segddin parameter RETRAC was changed so that a value less than 0 
means the traces will be renumbered so the channel numbers are accumulated 
across channel sets.  e.g. rather than 1-468, 1-468, 1-468, 1-468 they are
renumbered 1-1872.

comparing geom type 20 (determining gxp, ggx, dbrps from UKOOA) and type 8 (straight UKOOA)
type 8 source 1 streamer 1: trace 1, range = 6095        trace 436, range = 256
type 8 source 1 streamer 2: trace 1, range = 6071        trace 436, range = 180
type 8 source 1 streamer 3: trace 1, range = 6069        trace 436, range = 209
type 8 source 1 streamer 4: trace 1, range = 6056        trace 436, range = 298
type 8 source 2 streamer 1: trace 1, range = 6104        trace 436, range = 307
type 8 source 2 streamer 2: trace 1, range = 6078        trace 436, range = 205
type 8 source 2 streamer 3: trace 1, range = 6075        trace 436, range = 188
type 8 source 2 streamer 4: trace 1, range = 6061        trace 436, range = 249
type 20 streamer 1 (source 1): trace 1, range = -6094    trace 436, range = -256
type 20 streamer 2 (source 1): trace 1, range = -6018    trace 436, range = -180
type 20 streamer 3 (source 1): trace 1, range = -6047    trace 436, range = -209
type 20 streamer 4 (source 1): trace 1, range = -6136    trace 436, range = -298

Type 20 uses the first shot to determine the shooting geometry and is probably 
okay for the realtime 2-D stack.  I was surprised by some of the close trace (436)
ranges.  I know little about UKOOA file MGL11061164.p190.sample - it may be from
before shooting started and the streamers were not fully positioned.



Previous (2008) near Realtime processing aboard R/V Marcus Langseth
Explanation of script brute468 used in 2008.
Script brute468 quirks and "gotchas":
1)  uses  csh
2)  Assumes 468 traces
3)  Uses all traces (slow)  (ftr 1 ltr 468)
4)  Assumes the data are in channel set 2   (fcset 2 lcset 2)
5)  Assumes trace 468 is closest to the ship  (gxp 468 -250)
6)  Uses a shot to closest trace offset of 250.
7)  Uses a velocity function based on shooting near ridges where the
    sediment thickness and velocity vary by water depth.

Script used in 2010 to demonstrate near-realtime processing for a 2009 dataset.
This script is the same as brute468 except that the velocities are based
on the dataset being shot in a basin.  i.e. there is a single velocity
function "hung" from the watewr bottom.
The script still assumes 468 traces and an offset of 250.

Real-time stack script for 2011.
This script does not have to be changed when the streamer length (number of
channels) changes.

Changes from previous scripts:
1)  Requires a UKOOA file to be specified.  This file must have the correct
streamer offset to the closest hydrophone.  
2)  Only the closest 2km of the streamer are stacked (process tredit).
3)  The nmo velocity model is based on a layer cake from the water bottom
    (good for basins rather ridges).
4)  The steamer number must be given.  (If only 1 streamer, use 1.  This
    parameter sets the segddin fcset and lcset parameters).
5)  The source string number must be given.  (If only 1 source, use 0 so that
    every shot is read.  1 will read odd shots and 2 will read even shots).

    The entire trace is processed and plotted.  The script should be modified
to limit the amount of data processed by inserting segddin parameter secs.

    This script can be run on any machine, though the output plotfile must be 
accessible by the Sun computer (proc1) with the Atlantec plotter.
The plotfile is currently:    $outdir/$lineno-stack.atlantek
$outdir could/should be NSF mounted so that program    versatec
on the Sun can read it,

    Program ATLANTEK has been replaced by program VERSATEC.  VERSATEC
write to a file named 7225, which should be a link to /dev/ihcp0 on
compute stacker.  (ln -s /dev/ihcp0 7225)
    Program VERSATEC will plot two plots, one under the other, when
two plot files are given.  Each plot is the first half.  Process plot
parameter STIME may be used start the plot 

Thoughts about realtime QC for 4 streamers and two sources (Bang's)
Remember that sioseis has the ability to grab SEGD shots in realtime.
I) 8 stacks
   It might be useful to compare the 8 stacks as quickly as possible.  Compare
noise as well as amplitude.
   Using a variation of the above script, run 8 instances, one for each
shot-streamer combination.  Still use only the first 2km of the streamer.
The script writes the SEGY stack and an Atlantek plot file.
   Two "quirks":
   1)  only using 2km of the streamer
   2)  The plot scalar needs to be determined on the first line and each script
must be changed to use that scalar for ALL successive plots so that the
amplitudes are "true".
II) 8 "shots"
   A script can be written to display all 8 source-streamer combinations
in a single plot.  Plotting with nmo filter avenor enables background noise
(especially in the water column) and large noise spikes to be seen.  The 
streamer geometry needs to be known.  The avenor (average amplitude normalize)
is based on the water bottom depth, which brings all traces to the same plot
amplitude.

Plotting the last N stacked traces
in a single plot.  Plotting with nmo filter avenor enables background noise
(especially in the water column) and large noise spikes to be seen.  The 
streamer geometry needs to be known.  The avenor (average amplitude normalize)
is based on the water bottom depth, which brings all traces to the same plot
amplitude.

Plotting the last N stacked traces
SIOSEIS ver 2011.2.7 (23 Mar. 2011) contains a new DISKIN parameter LNTODO,