Comments on the proposed update of Argo user’s manual following Seoul[1] meeting decisions
1Feedbacks on the "User's manual" update proposal sent on 13/02/2012
1.113/02/2012 Message from Thierry Carval: the manual update proposal is online for comments
Dear Megan and Argo-dm,
Thank you very much for this new version 2.4 of the trajectory file format.
I only have a very minor remark; on page 5, use "code" instead of "flag" for measurement_code.
I inserted your document in the draft of the next Argo user's manual.
The draft is available from :
Following Seoul's data-management meeting, this draft includes the following features, listed on page 8 in the "History of document" chapter :
- §2.3 Megan Scanderberg : update of trajectory format following Seoul trajectory & ADMT12 meeting
- §3.3 Thierry Carval : CNDC (conductivity) valid min is set to 8.5 instead of 60.0
- §2.2.3 Thierry Carval : vertical sampling scheme to manage profiles performed on different vertical axes
- §2.4 Esmee Vanwijk : meta-data format version 2.4
- §2.2.3 Thierry Carval : global attributes and parameter attributes for CF compatibility
All comments are welcome, before March 1st.
1.214/02/2012 02:50 Comments from Annie Wong
My main comments with this draft concern the multi-axis format for the single-cycle profiles files. I have attached an edited document here that contains the details. In addition, I'd like to draw your attention to the following:
- This is profile format version 2.3, not 2.4.
OK for 2.3 (a profile format version 2.3 was already described in the previous manual, however, no such file ever reached the GDACs).
- The variable "vertical sampling scheme" is not optional.
It is mandatory. This is the only means users have for finding out which profile is what.
OK, changed
- Should "vertical sampling scheme" be STRING64 or STRING256?
OK for STRING256
- I suggest you move the material on P.18 under "Notes on vertical sampling scheme" to P.13, and consider re-writing that introduction part.
The rest can go into the netcdf variable specifications. Please see my doc.
OK, I inserted your suggestions
- PRES_DOXY in Reference Table 3 should now be removed.
OK, removed. I do not remember how it appeared here.
- In Reference Table 16, please assign specific descriptive names.
"Bio-geochemical sampling" is not good. There are already oxygen, nitrate, chlorophyll, etc, being telemetered back to the DACs.
I made some edits to Table 16. Please see my doc. Please note that as far as I know, right now all near-surface samplings are non-pumped.
OK, I took your corrections.
A last point concerns Reference Table 11. Please add Test 20 "Questionable Argos position test". Again, please see my doc.
OK, added.
1.314/02/2012 05:15 Comments from Mizuho Hoshimoto
Thank you very much for the new version.
I have some comments.
-page 25 Should "comment" of "DATA_TYPE", "FORMAT_VERSION", "HANDBOOK_VERSION", "REFERENCE_DATE_TIME", "DATE_CREATION", "PROJECT_NAME", and "PI_NAME" change to "long_name"?
Yes, if I understand correctly the CF metadata convention, available at:
On page 3, read the sentence:
“Each variable in a netCDF file has an associated description which is provided by the attributes units, long_name, and standard_name. The units, and long_name attributes are defined in the NUG and the standard_name attribute is defined in this document.”
See also page 11.
-page 27 Don't you add "standard_name" and "axis" to "JULD", "LATITUDE", and "LONGITUDE"?
Sorry, I added these missing attributes
-page 28 <PARAM>s will need "standard_name".
I also added a standard_name to <PARAM> and <PARAM>_ADJUSTED
-page 35 We need "STRING1024" in the dimension section.
Added
-page 36 The sample of "FORMAT_VERSION" should be <2.4>.
Changed
-page 38 Should "comment" of "PI_NAME" change to "long_name"?
Yes, changed on page 38 and all the pages where “comment” exists without “long_name”
-page 48 Don't you change "comment" to "long_name" at "DATA_TYPE", "FORMAT_VERSION", "HANDBOOK_VERSION", and "DATE_CREATION"? Or, should we remain technical data format this time?
I changed all the pages where “comment” exists without “long_name”. This applies also to the technical data format. So I updated it toformat version to 2.4.
-page 58 About "FREQUENCY_DOXY" at table 3, the format checker of USGDAC says valid max is 25000.f, C format is %7.1, and fortran format is F7.1. I agree with the result of USGDAC format checker. The resolution should be 0.1f in that case.
Also, "Aandera" should be "Aanderaa"
Ok, changed.
-page 61 The table 5 needs "I: Iridium positioning". In that case, "(ARGOS)" should be removed from the title.
OK, I updated table 5.
-page 64 Please add to the table 8 "844 ARVOR, Seabird conductivity sensor" and "853 Solo2, Seabird conductivity sensor".
Table 9 also needs "IRIDIUM Iridium positioning system".
OK, added.
-page 66 Could you add "COOA" to table 12 for the objective analysis?
OK, added.
-page 70 Please change "Measurements at start of transmission" to "Measurements at start of transmission (TST)" for confirmation.
OK, done.
1.415/02/2012 02:24 Question from Mizuho Hoshimoto
I have a question. What is the difference between "FIRMWARE_VERSION" of profile file and "FIRMWARE_REVISION" of metadata file?
If these are same, we should use same name. I feel "FIRMWARE_VERSION" looks better.
I agree with you and think that "version" is more appropriate than "revision". I rename FIRMWARE_REVISION and MANUAL_REVISION into FIRMWARE_VERSION and MANUAL_VERSION.
1.515/02/2012 22:34 Comments from Claudia Schmid
Thierry, Megan and argo-dm,
attached are 3 files.
argo_dm_usermanual_20120210_draft_comments.txt has suggestions and questions for most sections of the user manual.
argo_dm_usermanual_20120210_config_CS.docis a revised version of the configuration section.
argo_dm_usermanual_20120210_code_CS.docis a revised version of the measurement code table.
Both 'doc' files contain suggestions and questions.
1.5.1argo_dm_usermanual_20120210_draft_comments.txt
I agree with Annie's changes to the beginning of the profile section.
p.5 : JULD_LOCATION: 2nd column has more JULD than JULD_LOCATION
no axis= "T" needed?
I corrected the JULD:xxx attributes that should be named JULD_LOCATION:xxx
There should be one time axis only in the file. The time axis is JULD, not JULD_LOCATION.
VERTICAL_SAMPLING_SCHEME:
2nd column
char VERTICAL_SAMPLING_SCHEME (N_PROF, STRING64);
VERTICAL_SAMPLING_SCHEME:long_name = "Vertical sampling scheme of the profile" ;
VERTICAL_SAMPLING_SCHEME:conventions = "Argo CTD sampling, Pump near
3rd column
This variable is mandatory.
Use vertical sampling scheme to differentiate and identify profiles from a
single-cycle with different vertical sampling schemes. See Table 16.
I agree with Annie on removing the "Note on vertical sampling scheme"
on page 16.
Table 16:
1 Continuous sampling Sampling continuously with bin-averaging
2 Discrete sampling Sampling at discrete pressure levels
3 Near surface, pump on Sampling near the surface, CTD pump on
4 Non-pumped near surface Sampling near the surface, pump off or secondary sensor packagewithout a pump
5 Secondary continuous sampling Sampling continuously with bin-averaging with secondary sensors
6 Secondary discrete sampling Sampling at discrete pressure levels with secondary sensors
7 Unknown Sampling scheme is not known
Explanations/motivation:
Removed CTD in 1 and 2, because many floats sample P, T, S & O2 together. For the
same reason I removed "Bio‐geo‐chemical sampling" and replaced it with 5 and 6.
TC: I added this proposal as an alternative in the manual. Your proposal is more general, so probably easier to manage (we avoid a series of sampling schemes related to various parameters such as nitrate, chlorophyll, carbon…).
We need to take a decision.
Now I'll go beyond the basics (some of this might belong in the cookbook, but
we do not have it yet, and it may be interesting for the user to find some more
detail in the user manual).
If a float measures P, T, S & O2 all of them would have NPROF=1, but it could
be that:
a) O2 is sampled for every second P, T, S (I'm just making this up)
b) O2 is sampled discretely while P, T, S is sampled continuously (or vice versa)
(I'm just making this up)
c) P, O2 is sampled separately from P, T, S and interpolated T, S are used to get
the density needed for O2 (this is real)
How should such cases be handled? Suggestions
(a) can use NPROF=1 for all.
(b) maybe use NPROF=2 for O2.
(c) use NPROF=2 for O2.
TC: case a, b, c are ok form me.
A remark on c: use flag 8 (interpolated) for T and S on the O2 profile (nprof = 2)
Table 3:
suggestion to change a few column names to match the names used on pages
17-18 in column 2.
Parameter long name -> long_name
Parameter standard name -> standard_name
Unit -> units
Valid min -> valid_min
Valid max -> valid_max
resolution is not shown in the table
TC: ok for the change on column names, done
I think that the parameter attribute "resolution" is a problematic.
The parameter attributes are general, valid for all argo data files. However, the resolution may vary from one sensor to the other, it may change between real-time data and delayed mode data.
Therefore, I think that we should remove the "resolution" parameter attribute.
We need to take a decision.
comment: do we need it (on p.17-18 column 2 as well as in table 3
column 4)?
Profiles are in situ by default. If we delete it, then the other columns
in table 3 become more readable. Some of the information in comment can
go in the column long_name (which currently has the same entry as the
column name for the oxygen-related variables).
TC: I am ok to remove the "comment" attribute on parameters.
Does someone disagree?
Examples:
VOLTAGE_DOXY in colum 2 could be replace with
"Voltage reported by oxygen sensor"
MOLAR_DOXY currently is described as "Technical value reported by sensors
such as Aanderaa Optode" This looks more like an Oxygen concentration to me
(based on the unit). So long_name could be "Molar oxygen concentration reported
by the oxygen sensor"
TC:OK, I also added the standard_name : mole_concentration_of_dissolved_molecular_oxygen_in_sea_water
PRES_DOXY long_name could be "Sea water pressure at the depth of oxygen sampling"
TC: ok, I added pres_doxy on table 3
The example on page 18 has no PRES_ADJUSTED (, ...) variables.
TC: I removed PRES from the example.
p. 19
Since we are changing so much, maybe we should change CALIBRATION_DATE
to SCIENTIFIC_CALIB_DATE?????
TC: ok
The current trajectory format version is 2.2 -> we will be at 2.3 with the new
one. Agreed?
TC : ok for 2.3 for trajectory and profile formats
p. 26
int MEASUREMENT_CODE (N_MEASUREMENT);
MEASUREMENT_CODE:long_name = "Number referring to an action or measurement by a float that
has a defined measurement code";
MEASUREMENT_CODE:conventions = "Argo reference table 15";
MEASUREMENT_CODE:_FillValue = 99999;
Codes for actions or measurements are given in Argo reference table 15.
Example:
The number 1 is assigned to measurements made at the start of descent to
the drift pressure. They could be time, location, surface pressure, etc.
JULD_*_STATUS
Regarding Megan's note: if we do not use the "0" STATUS, then a lot of the US floats
will have "9" for many of the times.
JULD_FIRST_STABILIZATION
Julian day (UTC) of the first stabilization after the start of descent to
the drift pressure.
Megan, do you agree?
JULD_DEEP_DESCENT_START
Julian day (UTC) of the start of the deep descent to profile pressure at the end
of the drift phase.
TC: Megan, do you agree?
JULD_END_TRANSMISSION
Rename it to JULD_TRANSMISSION_END to match the renamed JULD_TRANSMISSION_START
Same with it's STATUS.
TC: ok, done
CONFIGURATION_MISSION_NUMBER
Could not find section 2.5.4 found it in section 1.11.5
TC: I changed 2.5.4 into 2.4.5, is that correct?
CYCLE_NUMBER_ACTUAL
just a thought: should we call this CYCLE_NUMBER_SHORT
Why? Because both CYCLE_NUMBER and this variable contain the actual cycle number.
TC : Megan, do you agree?
Cycle number of the float. This variable will help to relate cycle timing
information and grounding status to the measurments collected during each cycle.
TC : Megan, do you agree?
HISTORY_PREVIOUS_VALUE
why are columns 1 and 2 green?
TC: I don't know, there is no good reason, I removed the green.
The current meta format version is 2.2 -> we will be at 2.3 with the new
one. Agreed?
TC: ok, changed
Should the clock drift be in the trajectory file?
TC: Esmee removed it from trajectory file toword the technical file with the name TIME_ClockDrift_DeciSECONDSperDay
PLATFORM_MAKER
Name of the manufacturer. Example : Webb Research Corporation
TC: OK
STANDARD_FORMAT_ID
Lots of brainstorming on this one.
a) this is not clear to me. Maybe it will be associated with the revision date
available from many manufacturers?
If so, the combination of platform maker, type, transmission system and
firmware revision, manua; revision will fully describe a float type. The
corresponding documentation could have a standardized file name that consists
of all the listed information. Maybe the STANDARD_FORMAT_ID could be
replaced with FLOAT_MANUAL_FILE_NAME (without giving the extension).
This file could then be made available through some web page (and it could
be found with a search engine).
b) if host site not yet determined, then what should we do when we start
implementing the new format?
TC: Esmee, can you comment?
DAC_FORMAT_ID
do we need this if we have a STANDARD_FORMAT_ID
TC: Esmee, can you comment?
Suggestion:
present the PLATFORM_FAMILY, PLATFORM_TYPE, PLATFORM_MAKER, FIRMWARE_REVISION,
MANUAL_REVISION
right next to each other, prefereably in the given order.
This could be followed by FLOAT_MANUAL_FILE_NAME or STANDARD_FORMAT_ID
TC: done
FLOAT_OWNER
The owner of the float (may be different from the data centre and operating agency).
Is this supposed to be filled with the name of a person or with the name
of an agency? How does it relate to the PI name (which is what I associate with
the float owner). Do we need a PI_INSTITUTION?
TC: Esmee can you comment and give an example ?
AGENCY versus INSTITUTION. In most (or all) cases we used INSTITUTION. So,
maybe we should use OPERATING_INSTITUTION instead of OPERATING_AGENCY.
What is an OPERATING_AGENCY (example)?
TC : ok for institution instead of agency.
Esmee, can you provide examples for each "Example:…"
ARGO_GROUP
what this means is not quite intuitive. Could not come up with a more meaningful
name. Any ideas anybody?
TC: …
END_MISSION_STATUS
Seems like if no dimension is given the length is 1 by default. True?
TC: I think it's true.
For 3. column: maybe add "T" -> No more transmission received, "R" -> Retrieved.
I know it is in column 2, but some users may not see it there.
TC: ok
Should there be a distinction between retrieved at sea and retrival of beached
floats?
Should there be a distinction between grounded and all other cases of no
more transmission received?
TC: Esmee can you comment?
CONFIG section
see argo_dm_usermanual_20120210_config_CS.doc
TC: Esmee can you comment? OK for me.
p. 43
ARGO_GROUP (see above)
BATTERY_TYPE - we'll have to permit "unknown"
BATTERY_PACKS - we'll have to permit "unknown"
DAC_FORMAT_ID - is string 16 long enough? (related to float characteristics section)
MANUAL_REVISION - we'll have to permit "unknown"
PTT - we'll have to permit n/a for Iridium and Orbcomm floats
TRANS_FREQUENCY - we'll have to permit "unknown"
TRANS_SYSTEM_ID - what is this for Iridium and Orbcomm?
TC: "unknown" means "we did look for this information, we could not find it and we think that we won't be able to find it"
Is that correct Esmee ?
p. 57-58
do we need the sub-section "Remark on unit conversion of oxygen"?
I think not. By removing it we avoid the potential for incosnsitencies
with the more detailed oxygen documentation on the ADMT web page.
TC: you are right; this remark has to be removed. The instructions to manage oxygen will be detailed in the cookbook.
p.67 (table 15)
suggestion for the first paragraph in this section:
In the trajectory file, each action of the float during the cycle is
associated with a code (measurement_code). One or more measurements
might be taken at the time of the action. The code allows matching
the measurements with specific times and actions during each cycle.
TC: I added you suggestion.
measurement code table:
see argo_dm_usermanual_20120210_code_CS.doc
TC : Megan, do you agree on the update of the " Measurement codes table" ?
1.616/02/2012 06:59 Comments from Kanako Sato
Thank you very much for the new version.
I have some comments.
1. page 38
STANDARD_FORMAT_ID and DAC_FORMAT_ID are notclear to me. What are we supposed toassign to these parameters?
Esmee proposes 2 tables to list and describe the valid formats. Is that correct?
Wouldn't you prefer 2 reference tables in the user's manual ?
2. page 44
Could you change 'float SENSOR_ACCURACY(N_PARAM)' to 'char SENSOR_ACCURACY(N_PARAM, STRING32)'?
'Processing Argo OXYGEN data at the DAC level
version 1.2' says that SENSOR_ACCURACY for aanderaa
oxygen sensor (Optode 3830/4330/4330F) must be assigned
'8 micromol/L or 5%'. So, data type of this parameter
should be not 'float' but 'char', and the dimension should be
'(N_PARAM, STRING32)'.
OK, done. I understand that we need to give a unit in addition to the accuracy value.
I updatedSENSOR_ACCURACY andSENSOR_RESOLUTION into character strings.
3. page 45
As Claudia said, we will have to permit n/a for Iridium floats.
OK
4. page 64
Could you add 'Iridium' to table 9?
At ADMT#12, it was agreed that a weighted average of all Iridium
fixes should be included in the profile file if we cannot receive GPS position.
Because our NEMO-IR floats cannot often get GPS postion, we would
often assign 'Iridium' to POSITIONING_SYSTEM in the profile file.
OK, added.
[1] Argo data management n°12 and Argo trajectory workshop held in Seoul in November 2011