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. 🙂
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:
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:
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…