Back to SIOSEIS Examples.          Go to the list of seismic processes.          Go to SIOSEIS introduction.

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,