MB-System Basic Plotting

(From my old blog, but a post that I like to go back to…)

Here’s how I put together a rough bathymetry plot of a couple of survey areas, overlaid with the track lines.

1) Created a list of the files that I wanted to plot. I got this from one of Kurts blog posts from the Revelle:

ls *_raw.all | awk '{print $1, 56}' > PatchLines

I’ve never used Awk before. I felt some guilt in just blindly copying Kurt’s Awk command – it felt like cheating. But it would have taken me a long time to figure out some alternative: either do it in Python or Bash or Matlab or something (time consuming), or figure out enough Awk that I could understand how to construct this command myself (ugh, even MORE time consuming). So I just blindly copied.

2) Used the MB-System command mbm_plot, which takes some arguments, and then creates an executable script that generates a GMT plot of the bathymetry.

mbm_plot -F-1 -IPatchLines -N -G1 -W1/2 -Z1050/2100

The -F is the format. I set it to a negative number to tell the program to look into the list of files in the PatchLines file (generated in step 1).

The next argument, -I gives the name of the file containing the list of files, along with the file identifier.

-N gets the tracklines on the plot.

-G1 generates color filled bathymetry data

-W1/2 tells the program to to use continuous color shading (instead of discrete), and I specified color palette 2 (high intensity colors)

-Z1050/2100 says that the depth color scale goes from 1050m to 2100m.

3) The previous step generated PatchLines.cmd. I run this using ./PatchLines.cmd, and wind up with a Patchlines.ps postscript file. Here’s the final product, bearing in mind that it is completely raw data (no corrections, no cleaning, no sound speed corrections, nothing):

And one from the grid survey:

Multibeam files and the Unix file command

My friend Kurt is trying to compile a collection of multibeam sonar file formats to eventually submit to the author of the Unix file command, and I’m trying to help him get the s7k data format added. He pointed me to this post, where he talks about the formats that he has, and the ones he’s looking for. He also gave me this link to an LDEO page where sonar data format documents for various sonars are made available. Cool! All of this reminds me of how I wanted to install GMT and MB-System on my computer… I wonder if my little netbook would be able to handle it.

Python for ray tracing

I just found some python scripts that I started writing about a year ago, including one in which I was trying to read in a sound speed profile through the water column, and using Snell’s law to compute a *very* simple piecewise ray trace.  So I create several beams that launch from one location (ie. a multibeam head), all departing a different launch angle between -75:75 degrees. The purpose of it is to see how much effect an incorrect sound speed profile will have on the estimate of the seafloor depth for each beam.  I already wrote it in Matlab, so re-writing it in Python was really just an exercise to learn Python.  I’d only ever gotten as far as asking the user which sound speed files to use.  I think it’s a good project for me to work through. 🙂

Smiling seafloor

One of the most frustrating things that I run into when processing multibeam echosounder data is a smiling seafloor.  When the sound speed profile is incorrect, the computed seafloor becomes curved either up or down.  This is because the effect of an incorrect profile is more pronounced on the longer ranges (outer beams) than at nadir.  So the data is either smiling or frowning.  I should also note that the smiling/frowning could arise from incorrect beam steering angle, which can also be caused by having the wrong sound speed reading at the sonar head.

I spend far too much time messing around with sound speed profiles during post processing.  In the ocean, the speed of sound profile can change rapidy – both spatially and temporally.  If the profile changes while you’re surveying, your data will be wrong.  An interesting paper published by some of my favorite people can be found here:

IHO paper:  Estimation of Sounding Uncertaintly from Measurements of Water Mass Variability

So a lot of times I’ll end up having a profile that’s not quite right, and having to tweak it in my processing software, which takes a really long time.  I read an interesting paper recently by some folks at the Acoustic Remote Sensing Group in Delft University of Technology:

Underwater Acoustic Measurements Conference 2009: An efficient method for reducing the sound speed induced errors in multibeam echosounder bathymetric measurements

This paper discusses using the overlapping area between parallel lines to obtain an estimate of the sound speed throughout the water column.  The authors assumes that in shallow water the sound speed profile can be approximated by a single value.  The differences between overlapping lines are minimized using a Gauss-Newton method.

I’d like to look into this in more detail, but also maybe look at approaching the problem in a slightly different way – what if we looked at the overlap between crosslines instead of parallel lines?  The sound speed smiley error doesn’t show up in the along-track direction.  So if you did a beam-by-beam analysis of one line versus the perpendicular line, you would see the sound speed profile pop out.  If you average the difference in depth between each of the beams and an interpolated position on the crossline, you would end up with an average representation of the smile…  Okay, I might need to think about this a bit more.  But I’m imagining somehow running your entire survey, and then running a crossline across the whole thing, and computing profiles over the entire area.  And then maybe doing a whole checkerboard grid – type survey, and doing a full blown analysis on spatial and temporal sound speed variation.  I may be getting ahead of myself a bit.  But I think it’s worth pondering…