10th Argo data management 2009 Toulouse User’s manual comment Here is a list of comments received on User’s manual version 2.2 since August 28 th. Jean-Philippe Rannou sent a message on September 9th with very interesting comments and remarks.

10th Argo data management 2009 Toulouse Technical files In the list of technical parameter names, it seems to me important to know if the information is directly decoded from float data (e.g. PROVOR time information (given by the float in tenths of hours)) or created/estimated by DACs programs (e.g. PROVOR date (and time) elaborated from float time information). Could such information be added in the table 14 (Ann’s excel file)?

10th Argo data management 2009 Toulouse Trajectory file Launch position: In cycle #0 of AOML TRAJ file, the float launch position and date are given. I propose that the other DACs to do the same. Note on launch location It is recommended to insert the launch date and position in cycle 0 as the first location of the trajectory.

10th Argo data management 2009 Toulouse Trajectory file First & last Argos message dates In AOML TRAJ files we can find, for each cycle, the date of the first and last Argos messages transmitted by the float. This information is important to estimate ASCENT_END and DESCENT_START dates and should be given by all DACs It is also very important to have these dates in case of bad data transmission. In this case, if there is not enough data to create a profile and no Argos location, it is the only way for the user to know that the float surfaced at the end of this cycle. Do we add a note on that in the User’s manual ?

10th Argo data management 2009 Toulouse Trajectory file APEX park measurements Most of the APEX floats give one "park" P, T and S "sampled just before instrument descends to target depth". This information encoded in the "technical" part of the float message is given in the TECH file. AOML duplicates these park PTS values in the TRAJ file (this is not the case at Coriolis). Should all the DACs do the same?

10th Argo data management 2009 Toulouse Trajectory file N_CYCLE definition is: Maximum number of cycles performed by the float. In Coriolis, we consider it as the number of cycles received from the float. This interpretation is not correct. I think that we should set N_CYCLE to the number of cycle performed by the float, including the cycles whose data were not received. Should all the DACs do the same?

10th Argo data management 2009 Toulouse Profile file APEX bottom measurement Some (old) versions of APEX floats give a "bottom" P, T and S "sampled just before instrument begins ascent". What can we do with this data, given in the TECH file? Should it be added to the profile (as the deepest point) like in Coriolis PROF files? Do we add a note on that in the User’s manual ?

10th Argo data management 2009 Toulouse Cycle 0 description In the introduction chapter the "cycle naming convention" paragraph is very difficult to understand for the cycle #0. As cycle #0 is a convention, it should be useful to explain what we call cycle #0 for each type of float and what information is given in NetCDF files for this particular cycle. Something like... For APEX floats, cycle #0 stands for the 6h surface drifting phase prior to the first dive. From this cycle we can find: - in the TRAJ file, the locations estimated by Argos during this phase. - in the TECH file, the float configuration parameters, transmitted by the float in its test message during this drifting phase. For PROVOR floats, cycle #0 stands for the first cycle achieved by the float. This cycle duration is different (generally shorter) from the next ones (given in CYCLE_TIME of META file). The parameters given for this cycle in the TECH, PROF and TRAJ files are the same as for the next cycles. etc....