MB-System Unix Manual Page

mbsystem

Section: MB-System 5.3 (1)
Updated: 7 June 2013
Index

NAME

mbsystem - A set of utilities for manipulating and processing swath sonar bathymetry, amplitude, and sidescan data.

VERSION

Version 5.3

AUTHORSHIP

David W. Caress (caress@mbari.org)

Monterey Bay Aquarium Research Institute
Dale N. Chayes (dale@ldeo.columbia.edu)

Lamont-Doherty Earth Observatory

INTRODUCTION

MB-System is a software package consisting of programs which manipulate, process, list, or display swath sonar bathymetry, amplitude, and sidescan data. This software is distributed freely (and for free) in the form of source code for Unix platforms. The heart of the system is an input/output library called MBIO which allows programs to work transparently with any of a number of supported swath sonar data formats. This approach has allowed the creation of "generic" utilities which can be applied in a uniform manner to sonar data from a variety of sources. Most of the programs are command-line tools, but the package does include graphical tools for editing swath bathymetry, editing navigation, modeling bathymetry calculation, and adjusting survey navigation.

The acronym MB stands for MultiBeam; this reflects the fact that the early development of MB-System focused on processing deep sea bathymetry data from ship-mounted multibeam sonars. However, MB-System now supports several data formats from sidescan and interferometric sonars and works with sonar data that map the seafloor at scales from centimeters to kilometers.

The original National Science Foundation (NSF) mandate in 1993 was to create a set of generic tools that would work with all of the sonar data collected on U.S. academic research vessels in NSF-supported projects. Not surprisingly, the early core of the MB-System user community consisted of NSF-supported researchers at U.S. institutions such as the Lamont-Doherty Earth Observatory, the Scripps Institution of Oceanography, and the Woods Hole Oceanographic Institution. However, in recent years MB-System has also come to be used widely in the international oceanographic community and in the marine technology industry.

The MB-System source code is distributed under the GNU General Public License as formulated by the GNU Project. MB-System installation depends on some other software packages (e.g. GMT and netCDF), all of which are freely available as source code.

COPYRIGHT AND LICENSING

MB-System Copyright (C) 1993-2012 by
David W. Caress (caress@mbari.org)
    Monterey Bay Aquarium Research Institute
    Moss Landing, CA 95039
Dale N. Chayes (dale@ldeo.columbia.edu)
    Lamont-Doherty Earth Observatory of Columbia University
    Palisades, NY 10964
All Rights Reserved
All Wrongs Remembered

The MB-System source code is distributed under the GNU General Public License as formulated by the GNU Project. Early MB-System distributions were described as "public domain", which meant there was no restrictions whatsoever on the use of the code. We adopted the more restrictive GNU GPL license in order to insure that anyone who distributes software based in whole or in part on MB-System also distributes the modified MB-System source code and any additional source code.

The GNU GPL also prohibits the distribution of proprietary executables linked with MB-System libraries unless the source code is also distributed. We waive this restriction on distributing proprietary compiled programs for specific software products if and only if those software products meet the following two conditions:

: 1) The software product was created, sold, and delivered to customers using source code derived from MB-System release 4.6 distributions.
: 2) The software product was sold and delivered to customers prior to January 1, 2001.

HISTORY

The development of MB-System began in 1990 as part of David Caress' research at the Lamont-Doherty Earth Observatory (LDEO), which involved swath bathymetry data collected with SeaBeam multibeam sonars. Development was accelerated in 1991 as part of an effort to support the new STN-Atlas Hydrosweep DS multibeam sonar on LDEO's ship, the R/V Maurice Ewing. Dale Chayes, a Lamont-Doherty engineer, was responsible for the maintenance and operation of the Ewing's Hydrosweep. As part of a grant in 1993 and 1994 to Chayes and Caress to upgrade the Hydrosweep operations on the Ewing, the National Science Foundation provided support to improve and extend MB-System. The intent of this initial grant was to provide a standard "generic" set of tools for processing and display of swath sonar data that could be used by the U.S. academic community. The first generally released version of MB-System (3.0) was made available in the Spring of 1993. This was followed by versions 3.1 and 3.2 in July, 1993, version 3.3 in November, 1993, and version 3.4 in December 1993. All of these early releases supported only SeaBeam and Hydrosweep data.

SeaBeam Instruments and Antarctic Support Associates provided additional support in 1994 for the development of MB-System, with particular emphasis on capabilities related to the new SeaBeam 2100 series of sonars. A considerably enhanced MB-System version 4.0 was released on October 22, 1994; this release followed an almost complete rewrite of the underlying source code. The new capabilities included support for sidescan as well as bathymetry data and support for data from a number of very different sonars.

The National Science Foundation funded a five year effort begun in 1995 to maintain and further develop MB-System. From 1994 to 1997, SeaBeam Instruments (a major multibeam sonar manufacturer and, at the time, the principal employer of David W. Caress) provided significant support for MB-System development and maintenance. Similarly, the Newport, RI office of the Science Applications International Corporation (SAIC) supported some MB-System development during 1997-1998, when David W. Caress worked there. Version 4.1 was released in November, 1994, followed by 4.2 in February 1995, 4.3 on March 12, 1996, 4.4 on August 27, 1996, and 4.5 on September 23, 1997.

David Caress joined the Monterey Bay Aquarium Research Institute (MBARI) in September, 1998. Version 4.6 was released on April 16, 1999. The final update to version 4.6 (4.6.10) was announced on March 8, 2000. The primary innovations during this period included support for the new generation of Simrad multibeam sonars and tools for generating data products that could be imported directly into GIS software packages.

The National Science Foundation has continued to support MB-System development through additional five year grants (2001-2006 & 2006-2011) to MBARI and L-DEO. The Packard Foundation matches the NSF support to Caress at MBARI. The version 5.0 release incorporated another substantial rewrite of the underlying code as well as providing significant new capabilities. Thirty one 5.0 "beta" distributions were released during 2001-2003, with the full 5.0.0 version released on December 5, 2003. Active development continued with 5.1.0 released on November 26, 2006, 5.1.1 on December 31, 2008. and 5.1.2 on December 31, 2009. Since the advent of 5.0, over sixty "beta" and "official" distributions of MB-System have been released. Beginning with 5.2.1880 on December 30, 2010, MB-System distributions are tied to the revisions in the source code archive (the third number corresponds to the revision id in the archive).

Since 2004 a major theme of MB-System development has been the processing of multibeam, sidescan, and subbottom profiler data collected on submerged platforms, particularly autonomous underwater vehicles (AUVs).

WHAT'S NEW ABOUT VERSION 5

The version 5.0 release of MB-System included a number of changes and improvements relative to the version 4 releases. The most significant changes included:

A new approach to managing data processing.

*: Many tools - one output file. In previous versions of MB-System, each processing program read an input swath data file and produced an output swath data file. This "serial" processing scheme generally produced a large number of intermediate data files. MB-System version 5.0 features the integration of the editing and analysis tools with a single program, mbprocess, that outputs processed data files. The new "parallel" processing scheme covers bathymetry data processing, but does not yet incorporate the sidescan processing capabilities. All of the old tools and capabilities are still part of the distribution.
*: Recursive datalists. The lists of data files used by gridding and plotting programs can now be recursive, making it simpler to manage data from many different surveys.
*: Automatic format identification. MB-System programs will now attempt to automatically identify the swath data format based on the filename suffix.
*: Ancillary data files. Many common MB-System tasks (e.g. swath plotting and gridding) can be accomplished more rapidly using ancillary data files containing file statistics (".inf" files), quickly read bathymetry (".fbt" files), and (".fnv") files. Each of these files is named by adding the indicated four character suffix to the original swath data filename. The ".inf" files are created by directing the output of mbinfo to a file. The ".fbt" files are creating by using mbcopy to extract the bathymetry into a format 71 file. The ".fnv" files are created using mblist to create a text navigation list. These ancillary files are automatically created together using the program mbdatalist.

New tools.

*: mbnavadjust. This new tool allows users to adjust poorly navigated surveys by matching features in overlapping swathes. It is particularly useful for processing surveys conducted from submerged platforms.
*: mbprocess. This new tool performs a variety of processing tasks and produces a single output processed swath data file. The program mbprocess can apply bathymetry edits from mbedit and mbclean, navigation edits from mbnavedit, sound velocity profile changes from mbvelocitytool, and a variety of other corrections.
*: mbset. This new tool allows users to create and modify the parameter files used to control the operation of mbprocess.
*: mbdatalist. This new tool allows users to list the files referenced by a recursive datalist structure. It can also be used to create the ancillary ".inf", ".fbt", and ".fnv" files for all of the data files referenced in a recursive datalist structure.
*: mbsvplist. This new tool lists water sound velocity profiles embedded in swath data files, creating secondary files that can be read into MBvelocitytool.
*: mbareaclean. This new tool identifies and flags artifacts in swath sonar bathymetry data within a specified area of interest. The area is divided into a grid with square cells or bins, and the data are grouped according to these bins. Once all of data are read, statistical tests are applied to the soundings within each bin.

Support for Projected Coordinate Systems.

*: MB-System now incorporates the source code for the PROJ.4 Cartographic Projections library, providing support for (apparently) all commonly used geodetic coordinate systems. PROJ.4 was developed by Gerald Evenden (then of the USGS), and was obtained from the www.remotesensing.org website.
*: A large number of commonly used projected coordinate systems (e.g. UTM) are defined in a file (mbsystem/share/projections.dat) distributed with MB-System. These include all of the standard UTM zones, all of the standard state plate coordinate systems, and most of the European Petroleum Survey Group (EPSG) coordinate systems (also including UTM).
*: MB-System can now handle swath data that is navigated in a supported projected coordinate system. In particular, data files that are navigated with UTM eastings and northings instead of longitude and latitude can now be plotted and processed with MB-System.
*: The programs mbgrid and mbmosaic can now output grids and mosaics in any of the projected coordinate systems specified in mbsystem/share/projections.dat.
*: The TIFF images generated with mbm_grdtiff and mbgrdtiff now fully conform to the GeoTIFF standard, providing that the source grids or mosaics were generated using mbgrid or mbmosaic in either Geographic coordinates, UTM coordinates, or any of the EPSG coordinate systems specified in the projections.dat file. This means, for instance, that GeoTIFF images generated with mbgrdtiff will be properly georeferenced when they are imported into ESRI ArcGIS or other GIS packages.

Restructuring the code.

*: All of the C code now conforms to the ANSI C standard.
*: The underlying input/output library (MBIO) has been substantially rewritten. The structure has been streamlined, simplifying both future development and support of the existing code. The MBIO API has been greatly modified.

Handling of old Simrad multibeam data.

*: Vendor format data from the old Simrad multibeams (pre-1997 sonars) are now supported by a single format id (51) rather than a separate format id for each sonar model. The old format id's are automatically aliased to 51, so existing shellscripts will continue to work.
*: MB-System no longer supports beam flagging in format 51 data. The use of mbedit and mbclean on format 51 data will cause the flagged beams to be irrevocably nulled. Previous versions of MB-System used the highest bit in the depth values to represent beam flags because no Simrad data seemed to use that bit. We have not obtained data with depth values using the full bit-range, conflicting with the old beam flagging scheme. We recommend that old Simrad data be translated to the extended processing format (57) which contains proper beam flags and supports all processing functions. Format 57 is also used for processing data from the current Simrad multibeam sonars.
*: Sidescan data from old Simrad multibeams (pre-1997 sonars) are now handled in the same manner as data from the newer sonars (e.g. EM3000, EM3000, EM120). The raw samples in the vendor data format are binned, averaged, and interpolated into a 1024 pixel sidescan swath. This binned sidescan is not saved in the vendor format, so (as above) it is recommended that the data be translated to an extended format (57) that stores both bathymetry beam flags and processed sidescan.

Streamlining of MB-System Default Parameters.

*: Prior to version 5.0, the MB-System defaults set by mbdefaults included the format id, a control for ping averaging, longitude and latitude bounds for windowing by area, and begin and end times for windowing in time. These values are no longer set in the .mbio_defaults file or controlled by mbdefaults. As noted above, the format id is automatically identified from the filename when possible. When filenames do not match one of the recognized structures, users must specify the format using the relevant programs -Fformat option. The controls for ping averaging and windowing in time and space are rarely used, and must now be explicitly set in command line arguments.

New Data Formats.

*: Furuno HS10 multibeam bathymetry is supported as format 171.
*: SeaBeam 2120 multibeam data in the L3 Communications XSE format are supported as format 94 (already used to support Elac Bottomchart MkII XSE data).
*: Raw STN Atlas multibeam data generated by the upgraded Hydrosweep DS2 multibeam on the R/V Ewing are supported by read-only format 182. Processing is supported using the augmented read-write format 183.
*: The IFREMER netCDF multibeam archiving data format is supported as format 75. Similarly, the IFREMER netCDF navigation archiving data format is supported as format 167.
*: The STN Atlas processing data format SURF is supported as format 181. At present, SURF is supported as a read-only format. This allows plotting and gridding of the SURF data, but not processing. Writing or translating the SURF data to allow processing will be supported in a later version.
*: The Hawaii Mapping Research Group's new MR1 format is supported as format 64. This format is used to disseminate data from both the HMRG interferometric sonars (e.g. MR1) and the WHOI DSL 120 deep-towed inteferometric sonar. This format has been supported by including the code for the HMRG library libmr1pr in the MB-System MBIO library. Thanks to Roger Davis and HMRG for making the code available under the GPL.
*: The Edgetech Jstar format for sidescan and subbottom data is now supported as formats 132 and 133.

THE NEW VERSION 5 DATA PROCESSING STRUCTURE

Previous versions of MB-System have emphasized processing utilities that operate serially, that is, that read in an input swath data file, modify it, and then output a second swath data file. Serial processing utilities do allow for great flexibility in processing because one uses only the programs required and, in general, the order in which the programs are used does matter. However, one consequence of serial processing has been that processing data frequently results in a large number of intermediate data files. For instance, if an EM300 data file called "mbari_1998_524.mb57" has spikes in the bathymetry, outliers in the navigation, and the bathymetry has been calculated using an incorrect model for the water sound speed structure, users of MB-System would previously have processed it with a sequence something like this:

     1) Run mbclean to automatically flag
        the obvious bathymetric artifacts.
            Input:  mbari_1998_524.mb57
            Output: mbari_1998_524_c.mb57

     2) Run mbedit to interactively flag
        bathymetric artifacts.
            Input:  mbari_1998_524_c.mb57
            Output: mbari_1998_524_ce.mb57

     3) Run mbnavedit to interactively clean
        the navigation.
            Input:  mbari_1998_524_ce.mb57
            Output: mbari_1998_524_cen.mb57

     4) Run mbvelocitytool to generate an
        appropriate sound velocity profile (SVP) for
        recalculating the bathymetry.
            Input:  mbari_1998_524_cen.mb57
            Output: good.svp

     5) Run mbbath to recalculate the
        bathymetry using the SVP file generated
        using mbvelocitytool.
            Input:  mbari_1998_524_cen.mb57
            Input:  good.svp
            Output: mbari_1998_524_cenb.mb57

     6) Run mbsimradmakess to recalculate the
            sidescan while ignoring sidescan samples
            from beams now flagged as bad.
            Input:  mbari_1998_524_cenb.mb57
            Output: mbari_1998_524_cenbs.mb57

     7) Run mbbackangle to calculate an amplitude
      vs grazing angle table for correcting
      sidescan.
            Input:  mbari_1998_524_cenbs.mb57
            Output: ampvsga.dat

     8) Run mbanglecorrect to correct the sidescan.
            Input:  mbari_1998_524_cenbs.mb57
            Input: ampvsga.dat
            Output: mbari_1998_524_cenbsc.mb57

The result of this processing includes the input swath data file, the final swath data file, and five intermediate swath data files. The impact of this approach on data storage requirements is obvious (though some users have ameliorated the issue by working with scripts that automatically delete unneeded data files or by piping data from one non-graphical process to another to avoid making intermediate files). The serial processing approach also presents data management problems because data files frequently have different processing requirements, even within a single survey. We have found that working with very large datasets can be awkward when only a minority of data files require navigation editing or bathymetric recalculation, or when some data files require multiple episodes of bathymetry and navigation editing.

MB-System version 5 includes new utilities implementing a parallel processing scheme that simplifies the processing of most swath data. This scheme is centered around the program mbprocess, which can accomplish the following processing tasks in a single step:

*: Merge edited navigation generated by mbnavedit.
*: Apply bathymetry edit flags from mbedit and mbclean
*: Recalculate bathymetry from raw travel time and angle data by raytracing through water sound speed models from mbvelocitytool or mbsvplist.
*: Apply changes to roll bias, pitch bias, heading bias, and draft values.
*: Recalculate sidescan from raw backscatter samples (Simrad multibeam data only).
*: Recalculate sidescan from raw backscatter samples (Simrad multibeam data only).
*: Correct sidescan for amplitude vs grazing angle patterns.
*: Apply tides to bathymetry.

The actions of mbprocess are controlled by text parameter files. Each mbprocess parameter file is named by adding a ".par" suffix to the associated input swath data file and contains single line commands that set processing modes and parameters. Tools such as mbedit, mbnavedit, and mbclean all generate and/or modify parameter files in addition to generating parallel files used by mbprocess. The program mbset can also be used to create and modify mbprocess parameter files.

The same processing steps described above as a serial processing scheme can be accomplished with the new parallel processing scheme as follows:

     1) Run mbdatalist to create ancillary
        data files containing statistics
        (".inf"), quickly read bathymetry
        (".fbt"), and quickly read navigation
        (".fnv"). These files are used to
        speed common operations such as swath
        plotting and gridding.
            Input:  mbari_1998_524.mb57
            Output: mbari_1998_524.mb57.inf
                    mbari_1998_524.mb57.fbt
                    mbari_1998_524.mb57.fnv

     2) Run mbclean to identify
        the obvious bathymetric artifacts
        and output a list of the edit events.
        The parameter file is created and
        set to apply bathymetry flags from
        the ".esf" file.
            Input:  mbari_1998_524.mb57
            Output: mbari_1998_524.mb57.esf
                    mbari_1998_524.mb57.par

     3) Run mbedit to interactively
        identify bathymetric artifacts
        and output a list of the edit events.
        The existing edits from mbclean
        are loaded and applied prior to editing.
        The parameter file is updated and
        set to apply bathymetry flags from
        the ".esf" file.
            Input:  mbari_1998_524.mb57
                    mbari_1998_524.mb57.esf
                    mbari_1998_524.mb57.par
            Output: mbari_1998_524.mb57.esf
                    mbari_1998_524.mb57.par

     4) Run mbnavedit to interactively
        clean the navigation. The edited
        navigation is output to the ".nve" file.
        The parameter file is updated and
        set to merge the navigation from
        the ".nve" file.
            Input:  mbari_1998_524.mb57
                    mbari_1998_524.mb57.par
            Output: mbari_1998_524.mb57.nve
                    mbari_1998_524.mb57.par

     5) Run mbvelocitytool to generate an
        an appropriate sound velocity profile
        (SVP) for recalculating the bathymetry.
        The SVP is output to the ".svp" file.
        The parameter file is updated and
        set to recalculate the bathymetry by
        raytracing through the SVP model from
        the ".svp" file.
            Input:  mbari_1998_524.mb57
                    mbari_1998_524.mb57.par
            Output: mbari_1998_524.mb57.svp
                    mbari_1998_524.mb57.par

     6) Run mbbackangle to generate an
        a set of amplitude vs grazing angle
        tables at regular intervals in the
        data. These tables are placed into
        a single ".sga" file. The parameter
        file is updated and set to correct
        the sidescan by interpolating the
        amplitude vs grazing angle table for
        each ping.
            Input:  mbari_1998_524.mb57
                    mbari_1998_524.mb57.par
            Output: mbari_1998_524.mb57.sga
                    mbari_1998_524.mb57.par

     7) Run mbset to set the parameter file
        so that mbprocess will recalculate
        the sidescan (this is for Simrad
        multibeam data only) while ignoring
        sidescan samples from beams now flagged
        as bad.
            Input:  mbari_1998_524.mb57.par
            Output: mbari_1998_524.mb57.par

     8) Run mbprocess to apply the bathymetric
        edits, merge the cleaned navigation,
        recalculate the bathymetry, recalculate
        the sidescan, and correct the sidescan.
        The processed swath data is written to
        an output swath data file. The usual
        ancillary data files containing statistics,
        quickly read bathymetry, and quickly
        read navigation are also created.
            Input:  mbari_1998_524.mb57
                    mbari_1998_524.mb57.esf
                    mbari_1998_524.mb57.nve
                    mbari_1998_524.mb57.svp
                    mbari_1998_524.mb57.aga
                    mbari_1998_524.mb57.par
            Output: mbari_1998_524p.mb57
                    mbari_1998_524p.mb57.inf
                    mbari_1998_524p.mb57.fbt
                    mbari_1998_524p.mb57.fnv

The result of this processing is a single output swath data file. Moreover, the processed output can be easily updated if, for example, additional bathymetry editing is required. If the mbedit program is used again, it will load the existing edit events from the ".esf" file and then update the ".esf" file. To incorporate the updated bathymetry edits, one just runs mbprocess again. One can similarly change the SVP file without impacting on the bathymetry editing or navigation editing components of the processing.

All of the old, serial processing utilities are still distributed with MB-System. However, some of the serial tools have been replaced by new versions of the same name (e.g. mbedit, mbclean, mbbackangle, and mbnavedit). In these cases, the old versions are preserved as programs with "old" added to their names (e.g. mbeditold, mbcleanold, mbbackangleold, and mbnaveditold).

THE NEW VERSION 5 DATALIST FILES

Previous versions of MB-System have used lists of data files, or datalists, as input to several programs (e.g. mbgrid, mbmosaic, mbinfo, mblist, and mbm_plot). The basic datalist entry has consisted of a swath data name (often including the entire path) followed by a space and then the MB-System format id for that file. Datalist entry lines starting with the character '#' are considered comments. Version 5 extends the definition and usage of datalists in several significant ways. First, datalists may now be recursive. A datalist entry may be another datalist file, as indicated by a format id of -1. Second, datalists entries may contain a third column which is interpreted as a gridding weight value by mbgird. This third value may be used to weight some data higher than other data. For example, one might weight SeaBeam 2112 data with a value of 1.0 and lower quality SeaBeam classic data with a value of 0.001. The result would be that the newer 2112 data effectively overlies the less good data wherever overlap occurs. The third new feature of datalists works with data processed using the new parallel processing scheme. In the parallel processing scheme the raw data files are often, but not always, accompanied by processed files produced by mbprocess. It is awkward to maintain datalists that directly refer to the current best datafiles. If one inserts the text $PROCESSED into the first line of a datalist containing raw files, then programs like mbgrid will read the processed file if it exists, but otherwise will read the raw file. Similarly, a first line of $RAW will force the programs to only read the raw files directly referenced in the datalist. These options also work recursively. The first instance of a $PROCESSED or $RAW tag will prevail over all others encountered through a hierarchy of recursive datalists. The gridding weight values will also be applied recursively, so one can specify the gridding weight for a large number of data files by applying to a datalist entry which is itself a datalist referencing those files. However, gridding weights are by default overridden by any values applied to the file entries themselves (this behavior can be reversed using the datalist tag $NOLOCALWEIGHT).

VERSION 5 FILE NAMING CONVENTIONS

The version 5 MB-System programs make extensive use of standardized filename suffixes. These suffixes allow MB-System programs to know what kinds of files it is working with, and in particular to determine swath data formats without the user having to specify them. Although the processing will generally work even if a user does not use the standard filenaming convention, we can guarentee that the user's work will be much easier if the convention is followed. Quite simply, the convention is for swath files to end with a suffix of the format ".mbXX" or ".mbXXX", where XX or XXX is the two digit or three digit MB-System format id, respectively. For instance, a Simrad EM3000 file in the processing format 57 might have a name like:
        0053_20020518_205816.mb57

and a Reson 8101 file in the GSF format 121 might have a name like:
        039_2106.mb121

MB-System programs are able to recognize many standard filename conventions used by sonar vendors or data logging package vendors. For instance, filenames with a "_raw.all" suffix, like:
        0053_20020518_205816_raw.all

are recognized as either old (format 51) or new (format 56) Simrad multibeam data (and the programs also determine which of the two formats apply). Filenames ending with ".rec" are recognized as SeaBeam 2100 multibeam data. Filenames ending with ".xse" are known to be Elac Bottomchart or SeaBeam 2100 multibeam data in the XSE format 94. In these instances the program mbprocess will automatically replace the vendor suffix with the MB-System convention suffix when it creates a processed output file.

LIST OF MB-SYSTEM PROGRAMS AND MACROS

See the individual manual pages for detailed information about specific programs. See the manual page for MBIO for information about the i/o library and the swath sonar data formats supported by MBIO.

These are the MB-system programs which are used in the version 5 parallel processing scheme. Those programs that are also relevant to the serial processing scheme are marked with an *:
mb7k2jstar: Extract Jstar format (format 132) sidescan
                and subbottom data from Reson 7k (format 88)

                data files.

mb7k2ss: Extract sidescan sonar data from Reson 7k format
                data, bins and lays the sidescan onto the

                seafloor, and outputs files in the MBF_MBLDEOIH

                formst (MBIO format 71).

mb7kpreprocess: Preprocess Reson 7k data (MBIO format 88),
                including applying time lag and biases to

                attitude and navigation data.

mbhysweeppreprocess: Preprocess multibeam data in the
                Hysweep HSX format (MBIO format 201).

mbkongsbergpreprocess: Preprocess data from third generation
                Kongsberg multibeam sonars (MBIO formats 58 and 59).

mbbackangle:  Generates tables of the average
                amplitude or sidescan values as a

                function of the grazing angle with

                the seafloor at regular intervals in
                the data.

mbclean:  Automatically identifies and
                flags bad beams in swath sonar

                bathymetry data.

mbcontour*:  Generate GMT compatible Postscript
                color swath contour plots.

mbcopy*:  Copy swath sonar data files.
mbdatalist:  Parses recursive datalist files
                and outputs the  complete  list  of

                data  files,  formats,  and  file weights.

mbdefaults*:  Set or list default mbio parameters
                for reading and writing swath sonar data

mbedit:  Interactive editor used to flag bad
                beams in swath sonar bathymetry data.

mbextractsegy: Extract subbottom profiler or
                center beam reflection data to segy files.

mbformat*:   List information about swath sonar
                data formats supported by the MBIO library.

mbgetesf*:  Extract list of flagging or unflagging
                beam edit events from a swath sonar data

                file in the edit save file (".esf") format

                used by mbedit, mbclean, and

                mbprocess.

mbgrdtiff: Generate TIFF image from gridded data
mbgrdviz: Vizualize GMT grids.
mbgrid*:  Grid bathymetry, amplitude, and sidescan
                data from swath sonar data files.

mbhistogram*:  Obtain histogram of bathymetry,
                amplitude, or sidescan data from

                swath sonar data files.

mbinfo*:  Output some basic statistics of
                swath sonar data files.

mblevitus*:  Create a water velocity profile
                which is representative of the mean

                annual water column for a specified

                1 degree by 1 degree region.

mblist*:  List data in swath sonar data files.
mbmosaic*:  Mosaic sidescan and amplitude data.
mbnavadjust:  Interactive navigation adjustment
                package that adjusts navigation so

                that swath bathymetry matches where

                swathes overlap or cross.

mbnavedit:  Interactive editor used to fix
                problems with navigation in

                swath sonar data files.

mbnavlist*:  List navigation data in swath
                sonar data files.

mbneptune2esf: Extract bathymetry edits from
                Simrad Neptune software into edit save
                file format.

mbprocess: Performs a variety of processing
                tasks in a single step, including

                merging navigation, applying

                bathymetry edits, recalculating

                bathymetry, and recalculating

                sidescan.

mbps*:    Simple perspective views of swath
                bathymetry in Postscript.

mbrolltimelag:  Estimate attitude time lag by cross
                correlation of apparent bottom slope with the

                roll time series:

mbsegygrid: Generate time vs. trace number
                grids of seismic data from segy files.

mbsegyinfo: Output some basic statistics of
                segy seismic data files.

mbsegylist: List selected header values in
                segy seismic data files.

mbset:  Create and modify mbprocess
                parameter files.

mbsvplist*:  List water sound velocity profiles in swath
                sonar data files.

mbswath*:  Generate GMT compatible Postscript
                color and color shaded relief swath plots.

mbvelocitytool*:  Interactive program for
                modeling the affect of the water

                velocity profile on swath sonar

                bathymetry calculations.

The following are MB-system programs which are not used in the version 5 parallel processing scheme. These programs are included in the version 5 releases for backward compatibility with the old serial processing scheme:
mbhsdump:  Lists contents of the various sorts of
                data records in Hydrosweep DS data.

mbanglecorrect:  Apply a grazing angle correction
                to beam amplitude or sidescan data.

mbbackangle:  Generates a table of the average
                amplitude or sidescan values as a

                function of the grazing angle with

                the seafloor.

mbbath:  Generates bathymetry from travel times
                in swath sonar data.

mbcleanold:  Old tool that utomatically
                identifies and flags bad beams

                in swath sonar bathymetry data.

mbcut:  Removes data from portions of swath
                as specified by the user.

mbeditold:  Old interactive editor used to flag bad
                beams in swath sonar bathymetry data.

mbfilter:   Apply some simple filter functions
                to sidescan, beam amplitude, or

                bathymetry data.

mbgetmask:  Extract list of flagged or edited
                beams from a swath sonar data file.

mbmask:  Apply editing information obtained
                from one file with mbgetmask

                to another file.

mbmerge:  Merge swath sonar data with new
                navigation.

mbnaveditold:  Old interactive editor used to fix
                problems with navigation in

                swath sonar data files.

mbrollbias:  Evaluate the roll bias of a
                swath sonar system using two pieces

                of coincident bathymetry data

                collected with opposing ship headings.

mbsimradmakess:  Regenerate sidescan imagery
                from the raw amplitude samples contained

                in data from Simrad EM300 and EM3000 sonars.

mbtide:  Corrects swath sonar bathymetry
                for tide data.

mbunclean:  Unflags edited beams in swath sonar
                bathymetry data.

Macros are programs or shellscripts which make use of programs from the MB-system and other software packages to accomplish common tasks easily. These are the current MB-system macros:
mbm_arc2grd:  Convert an ESRI ArcView ASCII grid file
                to a GMT grid file.

mbm_copy:  Translate groups of swath data files
                between formats

mbm_dslnavfix:  Reads a WHOI DSL AMS-120 processed
                navigation file containing UTM northings

                and eastings and outputs a navigation file

                containing longitude and latitude which is

                suitable for use with mbmerge.

mbm_fmtvel:  Scans a Hydrosweep DS data file
                and outputs a formatted table of

                the mean water velocity and surface

                water velocity values used in

                processing that data.

mbm_grd2arc:  Converts a GMT grid file to an ESRI ArcView
                ASCII grid file.

mbm_grd2geovrml:  Create and execute commands which
                generate a TerraVision tileset and GeoVRML

                set  of  files  that can  be combined with

                other data and viewed in a web browser.

mbm_grd3dplot:  Reads a GMT GRD grid file and
                writes a shellscript which will

                generate a GMT 3D perspective view

                of the data.

mbm_grdcut:  Extracts a subarea of a GMT grid file.
mbm_grdplot:  Reads a GMT GRD grid file and
                writes a shellscript which will

                generate a GMT map of the data.

mbm_grdtiff:  Reads a GMT GRD grid file and writes a
                shellscript which will generate a TIFF image

                of the data.

mbm_grid:  Reads a swath sonar data file and writes a
                shellscript which will grid bathymetry data or

                mosaic sidescan (or amplitude) data using

                reasonable guesses at the appropriate grid

                bounds and bin size.

mbm_makedatalist: Generates an MB-System datalist
                file referencing  all identifiable swath

                files in the specified target directory.

mbm_plot:  Reads a swath sonar data file and
                writes a shellscript which will

                generate a swath and/or contour

                plot of the data.

mbm_rollerror:  Reads a swath sonar data file,
                calculates the noise in the vertical reference

                used by the sonar, and generates a file

                containing roll corrections which

                can be applied to the data.

mbm_route2mission:  Translate an mbgrdviz survey route
                file into an MBARI AUV mission script.

mbm_stat:  Runs mbinfo on a swath sonar data
                file and extracts beam statistics from

                the output of mbinfo.

mbm_utm: Performs forward and inverse UTM projections
                of ASCII data triples.

mbm_vrefcheck:  Generates a plot of high pass
                filtered apparent crosstrack seafloor slope.

mbm_xbt:  Processes a Sparton XBT data file
                and outputs a sound velocity profile

                file which can be used to process

                swath sonar data.

mbm_xyplot:  Reads one or more ASCII "X-Y"
                data files and writes a shellscript

                which will generate an XY plot of the data.

EXAMPLE PROCESSING APPROACH

An example processing stream for swath sonar data which uses the new, parallel processing scheme is provided here. Note that a '' character at the end of a line indicates that the command line should actually continue with the text on the next line. Refer to individual program manual pages for detailed information on the command arguments and functionality of the various programs.

PROCESSING SEABEAM 2100 DATA

The following data processing stream is recommended for data obtained with SeaBeam 2100 series multibeam sonars. A number of SeaBeam 2112 sonars were installed on academic research vessels during the 1990's, including the R/V Knorr and R/V Atlantis operated by the Woods Hole Oceanographic Institution, the R/V Revelle operated by the Scripps Institution of Oceanography, the R/V Ronald Brown operated by NOAA, R/V Mirai and R/V Kairai operated by JAMSTEC and other vessels. This same approach is appropriate for data from all other multibeam sonars, with small variations. The issues and differences associated with data from certain other types of sonars are discussed in the following sections.

Consider a data file "sb199411211212.rec" containing one hour's worth of SeaBeam 2112 data in the vendor format (format 41). This file contains bathymetry, beam amplitude, and sidescan data. The following commands are typical for processing such data and generating preliminary maps.

Step 1: What's in the data file?

First we run mbinfo to obtain statistics about the contents of the data file:

mbinfo -I sb199411211212.mb41

Seeing reasonable output assures us that we in fact know what kind of data we are processing.

Step 2: Generate ancillary files.

Next, we run mbdatalist to generate the statistics (".inf"), quickly read bathymetry (".fbt"), and quickly read navigation (".fnv") files that make many tasks run faster:

mbdatalist -I sb199411211212.mb41 \

-N -V

Running this program generates three output files, which we call ancillary files:
        sb199411211212.mb41.inf

        sb199411211212.mb41.fbt

        sb199411211212.mb41.fnv

Step 3: Generate first cut plota.

We are now set up to process the data. However, first we visually check the data by generating a swath plot of color filled bathymetry overlaid with contours and navigation. This is easily accomplished with mbm_plot:
        mbm_plot -I sb199411211212.mb41 \

                -G1 -C -N -V \

                -O ZSwathBathCont
        ZSwathBathCont.cmd

Here the ZSwathBathCont represents the plot name, and multiple files will be generated with names constructed by adding different suffixes to this name. The mbm_plot command generates a shellscript called ZSwathBathCont.cmd. Running this shellscript in turn generates a Postscript plot called ZSwathBathCont.ps, and then displays the plot to the screen using the Postscript viewer previously specified by the user with mbdefaults. The name ZSwathBathCont is descriptive but arbitrary. Users may specify any name they wish.

The types of swath plots produced by mbm_plot include:
     - color fill bathymetry with contours
     - shaded relief color fill bathymetry
     - color fill bathymetry overlaid with amplitude
     - grayscale amplitude
     - grayscale sidescan

We have already generated the first type of plot. We now generate the other four as well:
        mbm_plot -I sb199411211212.mb41 \

                -G2 -N -V \

                -O ZSwathBathShade

        ZSwathBathShade.cmd

        mbm_plot -I sb199411211212.mb41 \

                -G3 -S0/1 -N -V \

                -O ZSwathBathAmp

        ZSwathBathAmp.cmd

        mbm_plot -I sb199411211212.mb41 \

                -G4 -S -N -V \

                -O ZSwathAmp

        ZSwathAmp.cmd

        mbm_plot -I sb199411211212.mb41 \

                -G5 -S -N -V \

                -O ZSwathSS

        ZSwathSS.cmd

We use the -S option to apply histogram equalization to sidescan and amplitude data; note that for the bathymetry overlaid with amplitude map we use -S0/1 so that the the amplitude data used for shading is histogram equalized but the bathymetry is not.

Step 3: Apply Analysis Tools

We now have a reasonable idea of the data quality. There are several data analysis and editing tools that may be used to fix problems (or just to further investigate the data). These may be used in any order, at any time.

Analysis Option A: Automatic Bathymetry Editing.

The program mbclean applies some simple artifact detection algorithms to the bathymetry, effectively providing a means of automatically editing the bathymetry. We generally recommend that users edit the bathymetry interactively (see option B below) because no automated filter yet approaches (in our opinion) the ability of the human eye and brain to discern the difference between interesting seafloor morphology and sonar artifact. In particular, none of the filters available in mbclean come remotely close to performing satisfactorily in general. However, many users do find it useful to preprocess the data with mbclean before editing in the hope that many or most of the artifacts can flagged automatically. Again, we emphasize the importance of not depending solely on automatic filters. If you care about your data, look at it.

When we apply mbclean, we usually use a filter that flags all soundings that deviate more than a specified fraction of the local median depth from that median depth (the -G option). The choice of the filter or filters and the filter parameters used depends very much on the nature of the bathymetry data being processed:
mbclean -I sb199411211212.mb41 -G0.9/1.1 -V

If an "edit save file" named sb199411211212.mb41.esf already exists, mbclean reads this file and applies the pre-existing edits prior to beginning its filtering. All pre-existing edit events and all newly generated flags by mbclean are output to a new "edit save file", again called sb199411211212.mb41.esf. Since this is the first of the analyis programs to be run on this data file, mbclean also creates an mbprocess parameter file called sb199411211212.mb41.par which contains all of the parameters and settings to be used by mbprocess in generating a processed swath file. If the parameter file already existed, mbclean would modify it so that the bathymetry edits would be applied when mbprocess is run.

Analysis Option B: Interactive Bathymetry Editing.

We use the interactive graphical tool mbedit to check the quality of the bathymetry and to flag artifacts as necessary. We can start mbedit with the simple command:
mbedit

and then open a swath file using the pull down menus and dialogs. Alternatively, we can specify the swath file on the command line:
mbedit -I sb199411211212.mb41

While we are editing the bathymetry, all edit events, both flag and unflag, are written to an "edit save file" called sb199411211212.mb41.esf. This file is closed when the <Done> or <Quit> button is clicked. In turn, this file of edit events will be read and these events applied if we run mbclean, or mbprocess, or if we choose to run mbedit again. If this is the first of the analyis programs to be run on this data file, mbedit also creates an mbprocess parameter file called sb199411211212.mb41.par which contains all of the parameters and settings to be used by mbprocess in generating a processed swath file. If the parameter file already existed, mbedit would modify it so that the bathymetry edits would be applied when mbprocess is run.

Analysis Option C: Editing the navigation.

We use the interactive graphical tool mbnavedit to check the quality of the navigation and to fix problems as necessary. We can start mbnavedit with the simple command:
mbnavedit

and then open a swath file using the pull down menus and dialogs. Alternatively, we can specify the swath file on the command line:
mbnavedit -I sb199411211212.mb41

When we have completed editing the navigation, we click the <Done> or <Quit> button. The program then writes the final navigation to an "edited navigation" file called sb199411211212.mb41.nve. The program mbnavedit also modifies (or creates if needed) an mbprocess parameter file and sets it so that the edited navigation is read and merged with the swath data when mbprocess is run.

Analysis Option D: Modeling sound velocity profiles.

We use the interactive graphical tool mbvelocitytool to model the effect of altering the sound velocity profile (SVP) used to calculate bathymetry from the raw travel times and angles stored in the swath data. We can start mbvelocitytool with the simple command:
mbvelocitytool

and then open a swath file using the pull down menus and dialogs. Alternatively, we can specify the swath file on the command line:
mbvelocitytool -I sb199411211212.mb41

If the Levitus database has been installed, mbvelocitytool will attempt to run mblevitus to extract a reference sound velocity profile for the approximate location of the swath data file. This SVP will be displayed along with the editable SVP used for modeling. See the mbvelocitytool manual page for details on its operation. If we conclude that the bathymetry data include artifacts associated with having been calculated using an incorrect SVP, and we arrive through modeling at an SVP which is more likely correct, we save this SVP using the <File->Save swath svp file> menu button. Then mbvelocitytool saves the edited SVP in a file named sb199411211212.mb41.svp, and also sets (or creates if needed) the parameter file sb199411211212.mb41.par so that mbprocess will recalculate the bathymetry by raytracing through this SVP.

Analysis Option E: Correcting sidescan data.

We often find that sidescan imagery, despite the best efforts of sonar manufacturers, is dominated by a systematic variation in amplitude across the swath. Most commonly, the center or nadir region of the swath is characterized by high amplitudes, and the outer swath exhibits much lower amplitudes. This effect can be corrected by mbprocess provided that an appropriate model for the variation in amplitude with grazing angle is available. Since the amplitude vs grazing angle function varies with the type of seafloor, we need to construct separate amplitude vs grazing angle correction tables at regular intervals through each swath data file. We use the program mbbackangle to construct the amplitude vs. grazing angle tables:
mbbackangle -I sb199411211212.mb41 \

-P25 -N161/80 -V

Here a new table is constructed every 25 pings, and the tables will consist of 161 angle bins ranging from -80 degrees to +80 degress grazing angles. The tables are written by mbbackangle to an amplitude vs. grazing angle file called sb199411211212.mb41.sga. Of course, the program also sets (or creates if needed) the parameter file sb199411211212.mb41.par so that mbprocess will correct the sidescan.

Step 4: Process the data.

The program that actually takes the input, raw swath data and produces processed swath data is mbprocess. This program operates using the parameters listed in the parameter file sb199411211212.mb41.par. To process the data, we run
        mbprocess -I sb199411211212.mb41

The program produces an output processed swath file called sb199411211212p.mb41 (a 'p' character is inserted in the filename just before the MB-System suffix. The program mbprocess also automatically generates the three basic ancillary data files for the processed swath file:
        sb199411211212.mb41.inf

        sb199411211212.mb41.fbt

        sb199411211212.mb41.fnv

Step 5: Grid the bathymetry.

Now use mbgrid to grid the bathymetry. The greatest depth in the file is 4502 meters (from the mbinfo output). The 120 degree swath is 3.4 times the water depth wide, or 15.3 km wide. This translates to an average acrosstrack spacing of 15300 m / 120 = 127.5 m. If a region of a grid has more than one data point in each grid cell or bin, we say that this region is "oversampled". If some bins in a region have no data points, we say that this region is "undersampled". We choose a grid cell spacing of 150 m, which will cause the grid to be oversampled towards the center of the swath, but undersampled towards the edges of the swath.

The program mbgrid takes a datalist as input, so we first construct that file:
echo sb199411211212p.mb41 41 > datalist_grid

Now run mbgrid using the gaussian weighted mean algorithm (-F1) and longitude and latitude grid cell spacings of 150 m (-E150/150/m) to grid bathymetry (-A1). We use spline interpolation to fill in small gaps in the data no larger than two grid cells (-C2), and we set regions with no data to Nan values for compatibility with GMT programs (-N). We also specify -M so that grids of data density and data standard deviation will be generated:
        mbgrid -Idatalist_grid -E150/150/m \

                -R114.2208/114.4209/-31.9001/-31.6377 \

                -OZGridBath -A1 -N -C2 -M -V

The program mbgrid creates a shellscript which, when executed, will generate a color fill plot overlaid with contours of the gridded bathymetry. Now run that shellscript:
ZGridBath.cmd

Shellscripts have also been created to generate plots of the data density and standard deviation grids:
ZGridBath_bath_num.cmd

ZGridBath_bath_sd.cmd

Step 6: Mosaic the corrected sidescan data.

The program mbmosaic operates in a fashion similar to mbgrid, but has special capabilities allowing users to prioritize which parts of the swath are used in the mosaic that are useful for sidescan data. In particular, it is possible to create mosaics which do not use the nadir region of the swath except where no other data is available, or to create mosaics of sidescan data with particular look azimuths. The sidescan data has a higher resolution than the bathymetry so a smaller grid size can be appropriate. However, we wish to overlay the sidescan on the bathymetry, so we use the same grid cell spacing of 150 m.

In order to give the nadir region a lower priority than the outer parts of the sidescan swath, create a file of data priorities (priorities range from 0 to 1) as a function of apparent grazing angle (negative angles are on the port side of the swath, zero is at nadir, and positive angles are on the starboard side of the swath):
        -60.0 0.2

        -45.0 1.0

        -15.0 0.8

        -14.9 0.1

        14.9 0.1

        15.0 0.8

        45.0 1.0

        60.0 0.2

Here the nadir region has been set to a low priority and the highest priority has been given to data from an apparent grazing angle of 45 degrees.

Now run mbmosaic to mosaic the bathymetry corrected sidescan data (-A4):
        mbmosaic -Idatalist_grid -E150/150/m \

                -R114.2208/114.4209/-31.9001/-31.6377 \

                -Wangle_priority.dat -F0.10 \

                -OZMosaicSS -A4 -N -C2 -M -V

Now run the plot shellscripts to view the gridded sidescan data in grayscale and the ancillary data density and standard deviation plots:
        ZMosaicSS.cmd

        ZMosaicSS_num.cmd

        ZMosaicSS_sd.cmd

Step 7: Generate additional maps of the gridded data.

First, we use mbm_grdplot to generate a color shaded relief view of the bathymetry. We choose to illuminate the bathymetry from the northeast (azimuth of 45 degrees) and to use a shading magnitude of 0.4 (-A0.4/45). Because the data has been gridded as bathymetry (positive down) rather than as topography (positive up), the default plot will have "hot" colors for deep regions and "cold" colors for shallow regions; this is the opposite of the convention we usually use. In order to fix the colors, we have to either rescale the data by multiplying the bathymetry by -1 (accomplished with -MGS-1), or flip the color palette (accomplished with -D). We use the latter approach. Finally, because this grid is so small, the default shaded relief image is likely to be grainy. To fix this problem, we specify a dots per inch resolution of 72 (-MGQ72); this will take longer and generate a larger plotfile, but the plot will look better. We also use the -L option to specify the title and color scale label for the plot. Here is the command:
        mbm_grdplot -IZGridBath.grd \

                -G2 -A0.4/45 -D -MGQ72 -V \

                -L"Shaded Relief Bathymetry":"Depth (meters)" \

                -Osb199411211212_bathshade

        ZGridBathShade.cmd

Second, we use mbm_grdplot to generate a color fill view of the bathymetry overlaid with the gridded sidescan. The sidescan overlay is specified using the -K option. We want the colors for the bathymetry to be chosen without histogram equalization, but we also want histogram equalization to be applied to the sidescan data used for shading. To do this, we use -S0/1, where the first number (0) specifies no histogram equalization of the color scale and the second number (1) causes histogram equalization of the shading sidescan data to be implemented. In order to maintain the convention that high sidescan amplitudes are black, we flip both the color palette (as in the previous example) and the shading scale with -D1/1. We could also flip the shading by specifying a negative shading magnitude (-A-0.4). In this case, we forgo specifying the image resolution, resulting in a grainy plot:
        mbm_grdplot -IZGridBath.grd \

                -G3 -KZMosaicSS.grd \

                -S0/1 -D1/1 -A0.4 -V \

                -L"Bathymetry Overlaid With Sidescan":"Depth (meters)" \

                -OZGridBathSS

        ZGridBathSS.cmd

Step 8: Generate 3D perspective views of the gridded data.

Now, generate a 3D perspective view of the gridded bathymetry with shading through synthetic illumination (-G2) using the macro mbm_grd3dplot. The grid file is in bathymetry (positive down) rather in topography (positive up), so the bathymetry needs to be rescaled by multiplying by -1 (-MGS-1). We choose an illumination magnitude of 0.4 and an illumination azimuth of 45 degrees (-A0.4/45). We also choose a perspective azimuth of 250 degrees and an elevation of 30 degrees (-E240/30):
        mbm_grd3dplot -IZGridBath.grd \

                -G2 -A0.4/45 -E250/30 -MGS-1 -V \

                -OZGridBath3D

        ZGridBath3D.cmd

Now, generate a 3D perspective view of the gridded bathymetry shaded using the gridded sidescan data (-KZMosaicSS.grd). We want the sidescan data to be histogram equalized, so we use -S0/1. We also want the shading to be more prominent than the default shading magnitude of 0.2 would produce, so we use -A0.5:
        mbm_grd3dplot -IZGridBath.grd \

                -KZMosaicSS.grd \

                -G3 -A0.5 -E250/30 -D0/1 -S0/1 -MGS-1 -V \

                -Osb199411211212_bathss3d

        ZGridBathSS3D.cmd

PROCESSING THIRD GENERATION KONGSBERG MULTIBEAM DATA

The current generation of Kongsberg multibeam sonars (EM122, EM302, EM710) record data in files typically named with a *.all suffix. These binary files consist of many different data records, most of which are similarly structure but distinct from the records output by the earlier generations of Kongsberg (formerly Simrad) multibeams described in a later section. The raw Kongsberg format is supported in MB-System as format 58. However, format 58 lacks places to store some information that is important to processing. In particular, the raw Kongsberg format does not store beam flags, so the only to apply bathymetry edits is to null the flagged beams. This is not recommended, as it precludes unflagging flagged beams later determined to be good.

Also, the raw Kongsberg format stores the initial sidescan samples derived from subsampling the bottom returns in each of the formed beams. The locations of these samples on the seafloor are irregular, and the number of samples varies greatly from ping to ping. This raw sidescan is not well suited for mapmaking or processing because of the irregular locations. MB-System automatically bins and averages the available sidescan samples into a regularly spaced 1024 pixels with pixel sizes that vary only slightly from ping to ping. This resampled sidescan is what appears in swath plots and in the statistics reported by mbinfo. The raw format has no space to store the rebinned sidescan, so any corrections or other processing applied to the sidescan in formats 58 is lost.

We have defined a processing format (59) for Kongsberg multibeam that stores beam flags and rebinned sidescan in addition to all of the information in the raw file format 58. We strongly recommend that third generation Kongsberg multibeam data be translated into format 59 before processing. This can be accomplished, albeit unsatisfactorily, with mbcopy. For example, given a raw EM122 file called 0006_20111219_201329_METEOR_EM122.all, we can translate it to format 59 using:
        mbcopy -F58/59 -I 0006_20111219_201329_METEOR_EM122.all \

                -O 0006_20111219_201329_METEOR_EM122.mb59

If we have a number of EM122 files referenced through a datalist file called datalist_raw.mb-1, we can translate all of them using the macro mbm_copy:
        mbm_copy -F59 -I datalist_raw.mb-1

This macro simply executes mbcopy for each of the data referenced in the input datalist structure.

The problem with using mbcopy for translation between formats 58 and 59 is that the navigation, heading, and attitude contained in format 58 files are purely asynchronous, which means these values are defined according to their own time stamps and not the time stamps of the multibeam sonar pings. When format 58 data are read, the navigation, heading and attitude values must be read from their own data records and interpolated (or extrapolated) onto the time stamps of the multibeam pings for each survey record. This works fine if the relevant asynchronous navigation and attitude data are always found in the data files before the survey data from the same time, but that advantageious timing is neither assured nor common. A better approach is to use the tool mbkongsbergpreprocess to preprocess the Kongsberg multibeam data. This program makes two passes through reading each input file, the first to read and store the navigation and attitude data, and the second to properly interpolate the navigation and attitude values onto the multibeam survey pings. The usage is of the form:
mbkongsbergpreprocess -I datalist_raw.mb-1 -V

One further feature of Simrad multibeam data processing should be noted. Given that the raw sidescan samples are derived directly from the bottom returns identified by the sonar for each beam, it follows that whenever a bottom return pick is erroneous, the sidescan samples associated with that beam are also erroneous. Consequently, the binned sidescan shoulde be reprocessed following the application of beam flags to exclude the incorrect sidescan samples from the final imagery. Recalculating the Simrad sidescan is an mbprocess option which can set using mbset. To turn on sidescan calculation, we use:
        mbset -I 0006_20111219_201329_METEOR_EM122.mb59 \

                =PSSRECALCMOD:1 -V

We can also turn off sidescan recalculation using:
        mbset -I 0006_20111219_201329_METEOR_EM122.mb59 \

                =PSSRECALCMOD:0 -V

In practice, mbedit, mbeditviz and mbclean automatically set the parameter file to turn on sidescan recalculation when writing an "edit save file" for format 59 data, so users should not have to set this parameter manually.

PROCESSING OLDER KONGSBERG (FORMERLY SIMRAD) MULTIBEAM DATA

The older series of Simrad multibeam sonars (EM100, EM950, EM1000, EM12, EM12D, EM121A) recorded raw data in files typically named with an "_raw.all" suffix. These older data are supported in MB-System using format 51. The data from the second generation Simrad (Kongsberg) multibeams (EM3000, EM2000, EM1002, EM300, EM120) also come in files with the "_raw.all" suffix, but the format is different, and is supported by MB-System as format 56. MB-System programs can automatically discern the difference between the two formats, and so the initial identification of the data type is easy with mbinfo.

However, both formats 51 and 56 lack places to store some information that is important to processing. In particular, the raw Simrad formats do not store beam flags, so the only to apply bathymetry edits is to null the flagged beams. This is not recommended, as it precludes unflagging flagged beams later determined to be good.

Also, the raw Simrad formats store the initial sidescan samples derived from subsampling the bottom returns in each of the formed beams. The locations of these samples on the seafloor are irregular, and the number of samples varies greatly from ping to ping. This raw sidescan is not well suited for mapmaking or processing because of the irregular locations. MB-System automatically bins and averages the available sidescan samples into a regularly spaced 1024 pixels with pixel sizes that vary only slightly from ping to ping. This resampled sidescan is what appears in swath plots and in the statistics reported by mbinfo. The raw formats have no space to store the rebinned sidescan, so any corrections or other processing applied to the sidescan in formats 51 and 56 is lost.

We have defined a processing format (57) for Simrad multibeam that stores beam flags and rebinned sidescan in addition to all of the information in either of the raw file formats (51 and 56). We strongly recommend that Simrad multibeam data from both old and newer sonars be translated into format 57 before processing. This is accomplished with mbcopy. For example, given a raw EM1000 file called 0021_19960714_123418_raw.all, we translate it to format 57 using:
        mbcopy -F51/57 -I 0021_19960714_123418_raw.all \

                -O 0021_19960714_123418_raw.mb57

Similarly, given a raw EM300 file called 0005_20020425_034057_raw.all, we translate it to format 57 using:
        mbcopy -F56/57 -I 0005_20020425_034057_raw.all \

                -O 0005_20020425_034057.mb57

One further feature of Simrad multibeam data processing should be noted. Given that the raw sidescan samples are derived directly from the bottom returns identified by the sonar for each beam, it follows that whenever a bottom return pick is erroneous, the sidescan samples associated with that beam are also erroneous. Consequently, the binned sidescan shoulde be reprocessed following the application of beam flags to exclude the incorrect sidescan samples from the final imagery. Recalculating the Simrad sidescan is an mbprocess option which can set using mbset. To turn on sidescan calculation, we use:
        mbset -I 0005_20020425_034057.mb57 \

                =PSSRECALCMOD:1 -V

We can also turn off sidescan recalculation using:
        mbset -I 0005_20020425_034057.mb57 \

                =PSSRECALCMOD:0 -V

In practice, mbedit and mbclean automatically set the parameter file to turn on sidescan recalculation when writing an "edit save file" for format 57 data, so users should not have to set this parameter manually.

PROCESSING HYDROSWEEP DS DATA

Hydrosweep DS sonars were used on the R/V Maurice Ewing (operated by the Lamont-Doherty Earth Observatory and the R/V Thomas Thompson (operated by the University of Washington) from the early 1990's until 2001. The raw data was logged in a text format (21) that is slow to read and write. We recommend that users confronted with format 21 data translate it to format 24 before processing. Format 24 is a binary data format that contains all of the information in the raw file, but is on the order of 15 times faster to read and write. We accomplish the translation using mbcopy:
mbcopy -F21/24 -Ihs_ew9204_134.mb21 \

-Ohsih_ew9204_134.mb24

We also strongly recommend that users of Hydrosweep DS data recalculate the bathymetry using raytracing through an appropriate SVP, whether obtained using mblevitus, mbvelocitytool, or from other sources. The sonar calculates the raw bathymetry using a homogeneous water velocity model, and the results are almost always inferior to those obtained by doing the full raytracing calculations with a correct SVP.

Hydrosweep DS data do not contain sidescan, but they do contain per beam amplitude data. The amplitude data may be corrected in the same fashion as the sidescan. We run mbbackangle with the -A1 option to operate on the amplitude data:
mbbackangle -I sb199411211212.mb41 \

-A1 -P25 -N161/80 -V

and then run mbprocess as usual.

PROCESSING HYDROSWEEP MD DATA

Processing Hydrosweep MD data is similar to processing Hydrosweep DS data. In particular, recalculating bathymetry from the travel times is necessary because the sonar uses a homogeneous water velocity model. The difference is simply in the data formats used. The raw Hydrosweep MD data files (typically named with a ".R" suffix) contain only the travel times; the sonar calculated bathymetry is contained in parallel files (typically named with a ".P" suffix). The ".R" files are supported as format 101. Format 102 data files contain bathymetry in addition to the travel times. To translate the data from format 101 to 102 we use:
mbcopy -F101/102 -Iys9409040607.R \

-Oys9409040607.mb102

Bathymetry equivalent to that generated by the sonar will automatically be calculated in the copy process (the data stream includes the mean water velocity used by the sonar).

Hydrosweep MD data do not contain sidescan, but they do contain per beam amplitude data. The amplitude data may be corrected in the same fashion as the sidescan. We run mbbackangle with the -A1 option to operate on the amplitude data:
mbbackangle -I sb199411211212.mb41 \

-A1 -P25 -N161/80 -V

and then run mbprocess as usual.