My Job Onboard

As you might imagine, most days on the ship follow a pretty similar routine.  This particular cruise, because there is really only one major scientific operation going on (mapping) is even more routine than the others that I have been on.  The only deck work for this cruise is occasionally going out to drop an XBT.  XBT’s look a little bit like a missile or torpedo with a lead tip and a thin copper wire attached to them.  You just drop it over the side and let the wire uncoil until it reaches its max depth (different XBT’s are rated for different depths), then cut the wire and finish. They are used to get a temperature profile in the water column, which is the main variable that affects the speed of sound (salinity and pressure also have an effect, but these don’t vary spatially as much as temperature).  It is important to know how the speed of sound in the water varies since it determines the travel time of the sound waves emitted by the sonar system and thus significantly affects the distance calculations used to determine water depths (bathymetry).  Sound speed in water is ~1500 m/s (5x faster than in air), and doesn’t vary a whole lot, but even small variations change the depth calculations. 

There are two main jobs during the mapping operations: watch-standing and data processing.  The students from U. of Iceland and the MATE program handle the watch-standing duties. These duties mostly consist of watching the data displays on a large panel of computer monitors (there are 37 total, but not all are being used), making sure that the instruments are running, and making both an electronic log and a digital log every 30 minutes of our position, course, etc.  They also log if there are any problems with any of the systems, when we launch an XBT, and when the ship makes a turn to start the next survey line.  The watch-standing job could probably be done by one person, but they have 2-3 of them on 4 hour watches (then 8 hours off), so most of the time they are just relaxing, chatting it up, listening to music, or on their laptops.  I was on watch-standing duties during my first cruise, but since we were doing a seismic survey we had to log which airguns fired every 3 minutes and did a lot of deck work both deploying and recovering the OBS’s, so it was a lot more “action-packed,” although I still had plenty of down time.

My job is to help my advisor with the data processing, which includes bathymetry, backscatter, gravity, and magnetic data.  So far, I have only actually been working on the backscatter data, although I will work on the other data types soon (I'm starting on bathymetry tonight).  Data processing involves copying the raw data files over from the ship server, then running a script, which is just a text file that calls various programs that are specialized to read the raw files, pull out the desired data (all of the data types are embedded in a single file), clean up obvious noise and artifacts, create a grid of the data, filter the grid to clean it up further and fill gaps, and then plot it in a visual format so we can actually see what it looks like.  The time-consuming part is in the beginning, getting the script written and working properly, and testing various options for filters and methods of cleaning up the data.  Once the script is written, it is pretty much an automated process of just running it each day on the latest data, with perhaps some minor changes if there was a storm and the data is particularly noisy or something like that.  For the backscatter data, I started with a script that was written by another professor at UH who was on the ship a few months ago, and modified it for our current cruise.  For me, that is always the easiest way to construct a script and learn how it works.  Since I have very little training in programming or coding, it is difficult for me to just write a script from scratch, so it always helps for me to start with a working script that someone else wrote. Then, I can look in detail at what they do in each step, read the man pages (a manual that describes what each of the individual programs in the script do and the various options that you can use), and modify it to suit the data that I am looking at.  For those who aren’t experienced with writing scripts, I’ll reproduce a couple selected lines here and explain them so you get the idea:

mblist -F-1 -Idatalist-pmb59-1 -R-38/-20/55/65 -D4 >! mb.xya.bi

mblist is a program included in a package of programs called mb-system (used solely for processing multibeam sonar data, hence the “mb” in the name). It is used to pull various data types (backscatter, bathymetry, navigation, etc) from the raw files and place it into a binary file “mb.xya.bi.” The –F option tells it what format the raw file is in (every sonar system has a slightly different output format), -I tells it the name of the file that contains a list of the raw files, -R gives the geographic range (minimum longitude/max longitude/min latitude/max latitude) where the program will look (it will ignore anything outside that range which can be useful for getting rid of data that is really badly located; we had some data points that were near the equator), -D tells it what type of data to pull out (4 indicates the amplitude of the sonar return, aka backscatter), the “>” just tells it the name of the file to put the data in, and the ! means to overwrite the file if it already exists.

set R = "-R-35.52/-29.45/57.72/59"

This is a standard way of setting a variable on a unix-based computer.  It’s just a short way to define something so you don’t have to write it out every time.  In this case, I’m defining the “R” variable as the numbers in quotes, so I don’t have to rewrite it every time I use the –R option in a program.  As I said above, the –R option gives the geographic range.  You can define any variable as anything, and then you refer to that variable later with a $ sign in front of it (e.g. $R, $X, $name, etc.).

xyz2grd mb2.xya.bi -bi3 $R -Gmba.grd -I.0002

xyz2grd is a program that is part of a package of programs called gmt (generic mapping tools), probably the most common set of programs that I use in data processing and mapping.  It reads the binary file from mblist and turns it into a grid, which is just a file that has an x (longitude) ,y (latitude), and z (sonar amplitude) value at each point in a grid. –bi3 tells it that the input (i) file is a 3 column binary (b) file, the $R is the –R variable from above, -G tells it the name of the grid file I’m creating, -I gives the grid cell spacing in degrees (.0002 degrees is ~20 m, although with longitude this decreases toward the poles).

grdfilter mba.grd -Fb.0022 -Gfilt.grd

grdfilter is a gmt filtering program that you use to remove spikes and smooth out data, or fill gaps in the data. mba.grd is the name of the grid file I created with xyz2grd, -F tells it the type of filter, “b”, and the filter width (.0022).  In this case I use a boxcar filter, which is a simple running average that goes through each point on the grid and computes the average value over .0022 degrees (~220 m, or 11 20 m grid cells, 5 on either side of the point that it is evaluating), and uses that as the value at that point. That way if you have a large spike in the data at one or two points or generally rough noisy data, it will be averaged out with the surrounding data points.  A wider filter will average more points and smooth the data more; the key is finding a balance between de-spiking and not averaging out real data that you want to keep. –G again just gives the name of the filtered grid.

grdimage mba_all.grd -JM7i $R -P -Css_eq.cpt -Ba60mg20m -Xc -Y.85i >! $name.ps

grdimage is the gmt program that actually creates a plot of the data. mba_all.grd is the name of the grid that I want to plot, -J gives the map projection type (M = Mercator), and the width of the data plot (7i = 7 inches), $R is the –R variable, -P indicates I want it in portrait orientation rather than landscape, -C is the color file to be used in plotting (it tells it what values of backscatter intensity (the z values in the grid) that correspond to what gray values), -B tells it the spacing of lat/lon labels on the map frame (a60m = annotate (print the lat or lon value) every 60 minutes, g20m = put grid lines every 20 minutes), -Xc tells it to center the plot on the page in the x direction, -Y.85i tells it to offset the base of the image .85 inches from the bottom of the page, > tells it the name of the image file (I define the “name” variable like I defined the $R variable), and the ! again means to overwrite if there is an existing file of that name. .ps means it is a postscript file, which is an uncompressed image file format.

ps2pdf $name.ps >! $name.pdf

ps2pdf is another standard unix program (i.e. not specific to gmt or mb-system) that simply converts a postscript file(.ps) into a smaller pdf file with little to no loss in resolution so it's much faster to view.

There are tons of more programs within mb-system and gmt that all do different things and all have their own options, but this gives some examples of the basic structure of the code in a script file.  In order to learn what each program and option does, you just read the man page for that program and play with the options until you get the desired results.  For those that found this a bit overwhelming, unfortunately it gets a lot more complicated when you start having to add loops to perform the same operations on multiple files and string all of these programs together in the right order to get the final grids and plots.  For me, the best way to learn all of this is always to start with a working script that someone else (usually my advisor) wrote, dissect and analyze it, and then modify it to suit my purposes.  Although my favorite part of the process is still the geologic interpretation and analysis of the final maps as opposed to the programming part, I have to admit it is extremely satisfying when you finally get the code running that you've been working on for hours or days (or weeks), and up pops a beautiful map of the seafloor.