ADCP file formats - CSIRO ASCII format 0.1. Naming convention The ASCII ADCP profile files have names of the general form a bb cc [dd] . e ff Below, every variation of each portion of the filename is highlighted and explained: f 9503.agp 20 minute integrated profiles (originally stood for 'Franklin') f 9503_60.agp 60 minute integrated profiles e_ 9503.agp ensemble (non-integrated) profiles f 95 03.agp year of cruise f95 03 .agp cruise number consecutive numbering where more than one file required. A new file is started each time there is a change in the data collection parameters which is sufficient to alter the f9503 01 .agp interpretation of the data. For example, change in the number of bins sampled would not warrant a new file, but change of bin length would because that changes the depths corresponding to each bin. water velocities given are relative to the f9503. a gp ship. The user must add in the ship's velocity from each profile header record to get absolute currents (as described later). f9503. c gp absolute or 'corrected' currents are given. f9503.a tr Transit navigation corrected profiles f9503.a gp GPS navigation corrected profiles f9503.a bt Bottom Track corrected profiles f9503.a sh uncorrected profiles - useful only for relative or shear data f9503.a ny a variety of correction types used. 0.2. Quality Control Statistics The basic quality control statistic is a composite of the two major data quality statistics produced by the logging system. It is: avqc = %Good / ( Verr + 0.05 ) where: %Good Percent Good pings after logging system screening RMS Error Velocity in m/s. (In Verr cruises prior to Fr 11/88 the "95% confidence interval" is used instead) This statistic is then a number with an possible range of 0-20, and an expected range of 0-10, with values of 0 to 4 indicating very poor data, and values above 8 being very good data. This statistic exists for each bin of each profile.The other quality statistic, called ipcok, comes from the profile integrating process. It is also referred to as the "attendance percentage".For each bin, it is the percentage of the profile period for which the data was acceptable. That is, if the data in a given bin (depth level) was usable in only half the ensembles during a given integration period, then for that bin ipcok=50. 0.3. Calculating the Bin Depth The depth to the centre of bin j, in metres, is approximately: depth(j) = draught + (plen + blen)/2 + delay + blen*(j-1) + blen/10 where draught - 4 m blen - bin length plen - pulse length delay - delay after transmit (also known as DTFB - Depth To First Bin). The depth bins are generated by the instrument using the assumption of a sound speed of 1475 m/s. The above approximation can therefore be refined by correcting for the approximate real sound speed, that is, by multiplying the above-derived depth by (estimated_real_sound_speed) / 1475. This sound speed estimate would be made by estimating the mean temperature, salinity and depth for the main study area. 1. Header records All files have the same format for the first three records. Record 1: is empty or has the version number of the processing system. Record 2: Contains the Data Acquisition System parameters for this data. The only thing of interest to you here are the first four values, which enable you to calculate depth of bins and maximum depth of sampling. read( 4,1000 ) ibin, iblen, iplen, idelay, tping, ibt, hcor, xcor, ichead, refon, refb1, refb2, evmax, wmax, bwmax 1000 format( x, 4i4, i5, 6x, i2, 2f6.2, 2i2, 2i4, 2f6.2, i5 ) where: ibin number of bins to sample iblen length of bins (in vertical metres) iplen length of pulses (in vertical metres) idelay delay after transmit (in vertical metres) tping minimum time between pings ibt 1 => bottom tracking enabled heading or compass hcor correction applied at acquisition transducer rotation xcor correction applied at acquisition ichead 1 => currents rotated to geographic coordinates refon,refb1,refb2realtime reference layer averaging setup threshold for ping by evmax ping data rejection on basis of error velocities (m/s) wmax vertical velocity realtime threshold (m/s) bandwidth data screen bwmax threshold (actually inactive) Record 3: Processing run parameters. Users should not need to be concerned with this. read( 4,1001 ) alnang, scfact, lcor, lref, irefmin, iref1, iref, isrbin, atndmin, icovmin, minpcbt, maxdel, btemax, lreqts, code 1001 format( f5.1,f7.4,x,l1,x,l1,i2,2i3,3i4,2i3,f4.2,x,l1,x,a) 2. General data format The 3 header records are described in "Header records". After these, the rest of the file comprises profiles which are read in the following manner: read( 4,1000,end=900 ) cstart, icover, lastgd, unav, vnav, cnav, alon, alat, ibcover, ibot, iqc1, iqc2, iper do i = 1,lastgd,4 last = min( i+3,lastgd ) read( 4,1100 ) ( u(j),v(j),avqc(j),ipcok(j), j =i,last ) enddo 1000 format( x, a20, i3, i4, 2f7.3, x, a3, 2f8.3, i3, i5, 2i3, i5 ) 1100 format( 4( 2f6.2, f4.1, i4 ) ) where cstart character*20 start date and time percentage of averaging icover period covered by acceptable ensembles lastgd bottom-most accepted bin in this profile ship's East-West unav velocity for the profile (m/s, +ve East) ship's North-South vnav velocity for the profile (m/s, +ve North) cnav character*3 navigation type code: cnav(1:1) = 'B' Bottom track velocity GPS cnav(2:2) = 'P' position-derived velocity cnav(3:3) = 'D' GPS direct velocity cnav = 'BTr' Bottom track velocity No navigation cnav = 'Unc' velocity (uncorrected) "navigation" velocity is actually that of cnav = 'rel' some reference layer, so corrected velocities will be relative to that layer. mean longitude of the alon profile, real degrees, +east mean latitude of the alat profile, real degrees, +north percentage of interfix ibcover period for which there was bottom depth information mean bottom depth of ibot ensembles for which a bottom depth was available mean of bottom track iqc1 error velocity (BT correction only) mean of ensemble percent iqc2 good bottom track pings (BT correction only). iper integration period in seconds East-West velocity of u(j) currents relative to ship, for each bin, m/s, +ve East North-South velocity of v(j) currents relative to ship, for each bin, m/s, +ve north Quality Control value for each bin. This is the mean of the basic QC statistic for this bin. avqc(j) (See section 0.2) In the case of ensemble files (e_*), avqc(j) is simply the Verr (see Section 4.3). the "attendance percentage", or the ipcok(j) percentage of the profile period for which there was good data in this bin. Note that the water velocities given are relative to the ship. To get absolute currents, add unav to u(j) and vnav to v(j). That is: do j = 1,lastgd Ucorrected(j) = unav + u(j) Vcorrected(j) = vnav + v(j) enddo To minimise the effects of gaps in data, either reference layer averaging or pre-corrected integration may have been used. Such details of the processing method are reported in the summary file and possibly the Data Report. Documentation is available describing these treatments. 2.1 Example - Contents of file f890701.agp The record numbers on the left are there for clarity - they are not present in the actual file. 1: 2: 60 8 8 4 100 35.50 1 0.00 0.00 1 1 3 6 0.50 9.90 999 3: 4: 17-MAY-89 16:40:00 79 39 3.140 -5.533 D 158.713 -40.391 79 4735 0 0 1200 5: -2.87 5.67 7.3 79 -2.81 5.65 8.1 79 -2.80 5.64 8.4 76 -2.79 5.65 8.6 76 6: -2.78 . . . . . . 2.1.1. Interpretation The top 3 records are the header described in "Header records" . The first profile began at 16:40 on 17-May-89 (UTC), icover is 79%, the deepest good bin is bin 39, the GPS ship's velocity is unav = 3.140, vnav = -5.533 m/s, only Direct GPS velocities were used, the mean position during this profile was 158.713 E 40.391 S, bottom information was available for 79% of the profile, mean bottom depth was 4735 m, and averaging period was 20 minutes.By adding in the ship's velocity, the absolute or corrected water velocities are obtained. The first 3 bins for the shown profile are: bin calc ship-relative velocity absolute velocity avqc ipcok depth (m) u v u v % 1 16.8 -2.87 5.67 0.27 0.14 7.3 79 2 24.8 -2.81 5.65 0.33 0.12 8.1 79 3 32.8 -2.80 5.64 0.34 0.11 8.4 76 3. Summary files A summary file may accompany each dataset. It list specifics of the treatments used in processing that dataset, then lists the name of each data file and the total number of profiles and good bins in the dataset.Summary files have the same name as the first file in a dataset, but with an additional suffix of ".sum" 3.0.1. Example - "f890701.agp.sum" SUMMARY OF ADCP PROFILES FOR FR8907 Correction code is dp 3beam correction is not being applied Data frm Start of cruise to End of cruise in 20 minute integrals using reference layer averaging. Ref layer bins 3, 6 Refmin 1 Calibration constants: alpha 1.44 beta 1.0065 Gyro post-corrected Warning threshold for dv/dt between ensemble: 0.0025 m/s/s Min "icover": 30, Min attendance for any bin: 15 f890701.agp First ens is # 1 of file 1 Deepest profile goes to depth 408 2137 profiles with a total of 32433 bins produced. 4. Notes on specific file types 4.1 .agp suffix files - profiles with GPS correction The profiles generated by combining ADCP and GPS navigation data are contained in files with the .agp suffix. There are two types of GPS data used to generate ensemble velocities: - direct velocity data generated by the Ashtech OEM GPS Sensor, which is reduced to an average for each ensemble. - position-derived velocity, which is derived from the ensemble end positions. Which type(s) of GPS velocities are used in any profile are indicated by the cnav flag in the profile header. 4.2 .abt suffix files - bottom track correction Where Bottom Track has been used, the summary file lists four extra processing parameters. These are unlikely to be of interest to the user, but are described below: bottom-track velocities are rejected if the btemax rms bottom-track error velocity exceeds the given threshold (in m/s). bottom-track velocites are rejected for any minpcbt ensemble where the bottom track percentage good of is less than the given threshold as above, except set a limit on the absolute minbt number as well as the percentage to catch sparse bottom track in small ensembles. reject ensembles where RDI bottom depth is maxdel more than 6 metres different from the chosen "correct" depth (usually from the PDR). 4.3 .any suffix files - profiles with bottom track and/or GPS correction The profiles generated by combining ADCP data with Bottom Track or GPS navigation data are contained in files with the .any suffix. The type(s) of navigation data which have been used in any profile are indicated by the cnav flag in the profile header (i.e. "B" for Bottom Track, "P" for position-derived velocity, and "D" for direct velocity data). The preference with which the navigational data has been applied is indicated by the last field in the third line of the .any file. e.g. "bpd" means that bottom track corrected ensemble data has been used in preference to ensemble data corrected using position-derived ship's velocity, which in turn has been used in preference to ensemble data corrected using direct velocity data. 4.4 e_ prefix files - no averaging done while processing These files contain the originally logged (usually 3 minute) averages, after screening and calibration. The quality statistics for each bin have different interpretations for this non-port-averaged data: - the avqc value can be ignored (it is simply the error velocity in m/s.) - ipcok is now the %Good value. Lower values correspond to less reliable data. Source Doc: /dpg/dpg/dop/doc Version: 3 Oct 1997 (Helen Beggs) Author: Jeff Dunn CSIRO Division of Oceanography 1995 This page last updated: 19 November 1997