SVP extraction and processing configuration
Qimera not only scans for and extracts SVP information from incoming multibeam files, it also sets the SVP processing configuration based on the SVPs found in the file and the metadata that is associated with them.
Extraction
Qimera scans the incoming multibeam file for SVP data and if it finds any, these are written into the file's metadata directory. Qimera will always warn the user about files that have one or more SVP casts with missing time of acquisition and/or position of acquisition. The user can provide this information at a later stage in the SVP Editor.
After the scan is complete, Qimera copies new instances of SVP observations to the project's SVP directory in the vessel folder associated with the incoming source file. Existing files in this directory are first checked to see if they are duplicates and only new SVP observations are added. This is necessary as many source items may share the same SVP observation, but the user will prefer to only have to deal with a single instance of the SVP observation. In the event that a user edits one of the SVP files, Qimera will compare incoming new SVP files against the original record in the SVP directory. This allows imports to occur with over-writing edits that a user might have made on a particular SVP cast.
Processing Configuration
Many imported multibeam data files require ray bending corrections. Given a set of multibeam data files and a set of SVP casts, it is necessary to provide a mechanism in which any given multibeam data file can be associated with one or more SVP casts for the purpose of ray bending corrections. This is done in Qimera by selecting a "Sound Velocity Strategy". The currently supported strategies are:
- Specific sound velocity profile: associate a single SVP file to a multibeam file
- Fixed velocity from surface sensor: use the sound velocity from the surface sensor (this is usually reported in the multibeam ping packets) to create an SVP with constant velocity across the entire depth range
- Fixed velocity from user specification: same as "Fixed velocity from surface sensor", however, the user specifies the sound velocity to use.
- Real-time scheduling: match the application of sound speed profiles as they were applied during acquisition
- Nearest in time: use the SVP times of observation to determine which is nearest in time for any given ping time. The selected SVP can vary on a ping-by-ping basis.
- Nearest in distance: use the SVP position of observation to determine which is nearest in distance for any given ping location. The selected SVP can vary on a ping-by-ping basis.
- Nearest in distance, within user specified time: Same as "nearest in distance", however, a time constraint imposes a maximum allowable time difference between the ping time and the SVPs being considered.
At the end of the data extraction from a multibeam source file, Qimera makes an attempt to configure the most reasonable SVP lookup strategy for the incoming source file. The following decision process is used for all incoming multibeam data that is supported by Qimera and it is based on the number of SVP observations found in the source file.
1) If no SVP is found, the multibeam file's SVP selection algorithm is configured as "Fixed velocity from surface sensor". This allows users to compute sounding footprints, although with a potential refraction artifact, using the single sound velocity measurement that is typically provided in the multibeam data ping packet. This value is typically a measurement from a surface sound speed sensor that is provided to the multibeam for beam forming and beam steering purposes. For this configuration option, the user is warned that Qimera has had to resort to using this approach due to lack of SVP measurements.
2) If one and only one SVP is found, the multibeam file's SVP selection algorithm is configured as "Specific sound velocity profile". This case will cover the vast majority of cases.
3) If multiple SVPs are found in the file, the strategy depends on the availability of additional metadata concerning the SVP:
3a) If there is sufficient information in the incoming source file to determine the time interval over which any given SVP was used, the file's selection algorithm is "Real-time scheduling". This forces the use of a lookup scheduling file which indicates the which SVP is to be used at any particular point in time. This mimics what would have been done in real-time during acquisition, hence the name "Real-time scheduling". The additional information that is required to determine this is the "time of application" of an SVP (note that this is different than the time of observation). This can currently be determined only for Kongsberg .all files and GSF files in which the SVP "time of application" field is populated.
3b) If there is insufficient information to reconstruct the times of application of the many SVP casts, Qimera attempts to configure a reasonable lookup strategy based on whether or not the file format supports recording of the SVP time of acquisition and its position. For all of the three scenarios below, the user is warned about the selection strategy that is being chosen on their behalf.
3b-1) If SVP positions are available but SVP observation times are not, the selection strategy is "Nearest in distance".
3b-2) If SVP times are available, the selection strategy is "Nearest in time".
3b-3) If SVP times and positions are not available, the selection strategy is "Fixed velocity from surface sensor".
All of these SVP Velocity Strategies can be changed at any time after data import. The Processing Settings Editor will not allow users to choose strategies when the SVP files that are in the project do not support the decision making process. For example, if one or more SVP casts are missing the position of observation, the user will not be able to choose "Nearest in distance" or "Nearest in distance, within time" until they provide the required missing information. The options that are unavailable to the user are grayed-out in the configuration dialog, and the mouse tool tip indicates the reason why any particular option is unavailable.