INTRODUCTIONWhile the Multi Channel Seismic portion of Lonsdale's Gulf of California cruise was dropped at the last minute, there were tremendous preparations. My goals for the project were: 1) Process ALL the data, including decon and FK migration, before leaving the ship at the end of the trip. The hope was to have PostScript files of the areas of high scientific value. 2) To setup and establish realtime processing capability similar to what I set up on the R/V Ewing. SIO has a 24 channel marine Geometrics Stratavisor for doing A/D. In the fall of 2003, it was decided to buy an iSys thermal raster plotter rather than upgrading to a 48 channel system. It was also decided to lease an analog streamer. A major factor in these decisions was that we knew a digital streamer was being designed and that we might want to abandon all the analog equipment soon.
STREAMERThe question was then what group space and length streamer to use. My thinking was that a 300m, 12.5m group spacing, streamer would be better than a 150m, 6.25m, streamer. Part of the survey was to be in shallow waters (but never less than 400m) with a fairly hard water bottom. My gut feeling was that the differential NMO between primary and water bottom multiple events would be better with a longer streamer. Likewise, velocity analysis might be viable with a longer streamer. I also rationalized that these data would never be postprocessed with processes where spatial aliasing would be a factor. In 500m water, the first multiple arrives ~1.2 secs (twt). With an 1600m/s event at 1.21 and a 1500m/s event at 1.22, after NMO at 1600m/s and stack: ranges 100 - 400 (24 channels with 12.5m groups)
ranges 100 - 250 (24 channels with 6.25m groups)
Shooting every 37.5m (~12.1 seconds at 6 kts) then gives 4 fold coverage at 6.25m subsurface resolution.
Return to SIOSEIS examples. Go to the list of seismic processes. Go to SIOSEIS introduction.
PLOTTINGData collection was to begin just a few hours out of port, so getting setup before leaving port seemed like a good idea. I could also determine if I had all the hardware. The iSys V12 was connected to the Geometrics via an HP 170X print server. The iSys "spewed paper" when the 170 was connected to the ship's network, so the V12 was moved to be directly attached to the Sun's parallel port. The V12 has a Centronics interface. It was determined that the V12 is not greyscale as promised. An entry was made in SIOSEIS process plot to generate raster plots for the B&W V12. The old Versatec driver program "plot2" was modified to include the three bytes needed to signal the V12 Centronics interface that the data were rasters. After a couple of days it was determined that the Versatec driver approach was totatly wrong, so a new program, sio2c, was written that simply converts SIOSEIS rasterfiles to iSys Centronics files. These files may be cat'd directly to the device or sent through the spooler. The V12 is current setup through a print spooler, but I suspect that won't work for realtime processing and plotting. I need to write directly to the device for that. At least long plots can be made on something besides the 36inch wide HP DesignJet.
NAVIGATION1) There is no way to shot by distance. 2) The ship usually does everything from the Trimble Tasman receiver in unsecure mode. 3) SIO no longer had the security keys. 4) It's non-trivial to switch from unsecure to secure mode. 5) The Trimble 200D is the only differential unit. 6) The Captain says differential coverage is lost 20nmi from San Diego. 7) The 200D does not feed to the lab, only the Tasman does. The ship might be driven by a different unit than what's being recorded. 8) The new GPS receiver with Vessel ID is GPS and DGPS and switches automatically. No WAAS. 8) There are 3 Ashtechs used as heading info for the ADCP, but they are unreliable and don't connect to other systems. 9) It's unclear to me if there's a POS MV system. Some people say yes and some no. 10) It's impossible to modify the current lab nav recording scheme, even just to add a tag for which GPS unit is being recorded. There's just too much legacy code. I recommend that a "smart" GPS be purchased so that it can be run independently from the ship's unit. The Geometrics should record this independent unit.
REALTIME PROCESSINGThe latest navigation and water depth are now available in files /scgscg/files/nav_out and /scgscg/files/dep_out. They are started as: nohup /usr/local/bin/ttydump -d /dev/term/9 -b 4800 -r GGA -c -f /scgscg/files/nav_out & nohup /usr/local/bin/ttydump -d /dev/term/10 -b 9600 -c -f /scgscg/files/dep_out & SIOSEIS process SEGDDIN should be modified so that: 1) It generates Geometrics file names based on parameter FFILEN. Geometrics file names seem to be consecutive. e.g. 1.sgd, 2.sgd, 3.sgd This may be preferable to look doing the ls -t trick. 2) SEGDDIN needs to loop checking for new Geometrics files in the shot directory. 3) SEGDDIN (or GEOM?) need to grab the navigation and water depth and insert it into the SEG-Y header. With appropriate checks!
High-Sea NetThe high speed (32.0 kbits/s down, 64.0 kbits/s up) link between the Revelle and UCSD failed and was unavailable.