Reports issued by ArgoRT processing system

Some details of the reporting system are given in the Programmer Notes.

Reports may be issued by most components of ArgoRT. When the system runs (automatically, or by user activation, reports are saved to file and emailled to designated operators. That is organised by strip_argos_message, so when the user invokes a component function and bypasses strip_argos_message then the report will only appear on the screen.

Report files are found in reports/ and named by their creation date/time.

There is presently no automated process to remove old report files. They may be kept indefinitely or an auto-purge could be organised.

Severity levels are given to indicate the degree of attention warranted by each report.

Report severity levels

1	2	3	4	5
fatal	error	adjustment/correction	warning	activity report

All level 1-3 reports require assessment, and the implications of level 4 reports should be understood by the operator.

Less common reports will often include the name of the m-file where you should look to understand how the report arose.

Details of particular reports

95 different reports can be issued by the software, so the following list is incomplete!

Level 1 **FATAL

No usable date info

If all the Argos fix times with a message are bad then there is no point in continuing to process it - in fact, we can't even confirm which profile it is, although in RT processing that is pretty obvious. Note that this report can occur when the first snippet of info has just arrived from a float (if there is no good date associated with it.) However, 6 hours later much more of the message may come through, with good times, and the problem vanishes! So - check back later before fussing!

Level 2 *Error

GETDBASE: Mandatory fields missed in spreadsheet row/col: 129 18

A value is missing in the spreadsheet which may cause ArgoRT to crash! If it is not obvious, find the col number (18 in the example) in the case statement in getdbase.m (18 = "reprate").

METADATA_NC: Incomplete Cal spreadsheet - cannot generate _meta.nc

A value is missing from the calibration spreadsheet page. These values are only used in populating metadata files, so this fault is not notified until attempt to make such a file for the float with the missing value. Fill in the gaps (regenerating the .csv etc), restart Matlab, and rerun processing from workfiles to have the metadata file regenerated, or do it directly (use getargo and metadata_nc).

Old files in export/, first is 5901166_meta

export_argo copies files into export/ then spawns writeGDAC to do the ftp-ing. When completed copying to both GDACs, writeGDAC then deletes all files from export/. So, if files are hanging around in export/ it most likely means that writeGDAC is falling over before completion, which, unfortunately, happens without report because is it a spawned script.

Action: find out why/where ftp is failing; maybe manually ftp files to either GDAC if they have missed out on them, delete files from export/.

Level 3 warning

QC_TESTS: Fix(1) rejected by speed wrt last profile

From the speed test in qc_tests.m, when speed between profiles appears high until we test against the present fix #2, so conclude that fix #1 is dodgy. This may be the case, but I'd check all such cases.

Unresolved excessive speeds between fixes

From between-fix speed test in process-profile. A minimum of 4 minutes is applied to time-between-fixes, and a max speed of 4m/s, to reduce frequency of these reports. Investigate all cases (either using pos_fix_check or edit_workfile). If clearly bad time or pos, probably reject that line. The first fix is generally taken as the time/location of the profile, so more important to have this one correct.

N10_P10 exists, has been edited, and contains different data, so saving instead to N10_P10_A

(see also "Data in N10_P10 has changed "). There might be useful new data in this new file (obviously some problem initially because we have edited the original file.) Sadly, in order to use edit_workfile to test the new file it will have to be renamed "N10_P10.mat" - so before you do that you might make a copy of the original, in case you want to revert to it?

Level 4 action

Data in N10_P10 has changed (since stage 1?)

N10_P10.mat is a workfile. These are created during stage 1 processing, may be alterred using edit_workfile, and are overwritten during stage 2. If there is different content when overwriting, this action is reported. It simply means new messages have arrived. In such cases, if there was any fault with decoding the message in stage 1 then it might be worth reprocessing from the new workfile to make use of the new info.

Level 5 report