To be checked & resolved by Ann, Lisa

1. For Provor floats, is this correct? p_calibrate = p_raw - pres_offset; (line 26, calibrate_p.m)
2. Going by doco in Thermal Lag routines (see celltm_sbe41.m, and the original write_celltm_and_press_corr_apex_sbe41.m [which I have not used]), my thermal_lag_calc.m just uses a set of coefficients for SBE-41 floats, another for SBE-41CP, and otherwise gives up. Discussions on 14/11/06 revealled there may be other distinctions required.

   Also, ascent time in database is 8.47 hrs. Discussions in Thermal Lag correction code states that the real ascent rate is more like .09 dbar/s, which would give an ascent time of 6.17 hrs. Review other figures in the database.

3. Order of QC tests in qc_tests.m - this subtlety eluded me... (let me know if changes needed)
4. What about QC tests 18, 19?
5. Discussion of a tolerance set for the density inversion tes (#14). Easily done - let me know.
6. Should we record corrections/tests/adjustments as 'done' if the attempt to do them was made but not achieved because of lack of data or other condition. I generally think 'yes'. For example, we set the TL_cal_done=true if that the TL cal function is called for a given profile, whether or not the correction is aborted due to lack of data.
7. Density inversion test: both values involved in a density inversion ARE flagged (see qc_tests.m)
8. "DEEPEST PRESSURE" in metadata file was being set to 'profpres' from the database. I have replaced it with max(p_calibrate) for each profile. Ok?
9. Had prevously assessed jpeg and png. Tried again and still found no difference in image - in some browsers the images are scummy until you magnify, even when specify a higher quality level for jpeg (eg jpeg90). For now conclude that only gif is small but comes through browsers sweetly - jpeg & png have same failings but jpg are ~4 times the size!
10. Present coding uses only Argos fixes with BOTH good time and location. In places (such as footnote 1, pg 14, re JULD_LOCATION) it is implied that all times should be used, even those without locations. A rare occurence maybe, but could allow for it (although I really see little value in it, given that we should be able to estimate surfacing time pretty well.)

Recommended Future work

Field names for transmissometer data in netCDF files.

CTD Calibration

A lot could be tried and achieved here, because although reference CTDs are no doubt impeccable, they are few and rarely proximate to the given profile. Also, the variance test can be based on almost nothing - it surely should be replaced by a climatology value.

Oxygen Calibration (and screening)

already discussed ... could be a significant undertaking!

Plotting

It seems that one component that is more likely to fall over is the plotting, although this might become less likey with cleaner data. If it does crash then the processing run is unavoidably aborted, so it might be best to take plotting out of the processing run and have it as a second, follow-up program. In the BoM installation, the plotting could be on a user machine rather than on the 24/7 machine, but this will take a small amount of organising!

An alternative, if errors are occurring, is to put plotting in "try,catch" blocks. This is fine for "errors", but does not avoid "warnings", the latter being harmless anyway UNLESS using "dbstop if warning". For this reason, it is recommended that only "dbstop if error" is used in processing sessions (and even that is dubious!)

Web

Be good to have a map of last profile of every float Maybe maps of all locations for each float

failed FTP downloads

It would be pretty easy to check for ftp downloads that fail, especially if they fail early and not much comes through. This doesn't matter unless it is the last download for a day, in which case we may lose info permanently. If this becomes a frequent occurence, or especially if it happens several days in a row, we could save downloads to temporary files and overwrite the daily file only if the new version is not significantly smaller than the previous.

Optional developments

Saving netcdf files

Presently create GDAC netCDF Profile files in export/, and delete them from there then transfers are complete. Could choose to save them (by moving them to a permanent home instead of removing them.) If so, I suggest moving to a separate directory per float, in directory netcdf/. However, since these can be instantly generated from matfiles I do not see much point in saving them.

Daily web update

Could be run by normal programs (eg strip_argos_msg) if time is between 0600 and 1200, say, [hence once per day] instead of by cron job?

Also, the cron job should probably remove old daily html reports, because they don't need to be kept forever. The code is there but dormant in run_web_report.sh

Reporting "adjusted" data

Could have DATA_MODE set in argoprifile_nc.m by testing for non-empty s_calibrate, but for now hardcoded to 'A'. If not 'A', could leave all the "ADJUSTED" variables out of the netcdf files.

On algorithms and keeping faith with the previous system

Much detail, especially in decoding float messages, is taken from previous programs. Occasionally the previous code appears to be at odds with manufacturers'documentation (I follow the code rather than the doc.) At rare times I have decided not to follow previous algorithms in the belief that it was not performing as apparently intended. My overall test will be to replicate the performance of the old system. Some differences may arise (one source is in my initial use of the CRC and modified selection of most-common-value for messages,) but any unexplained differences will be invesitgated.

Last updated 16 Nov 2006