PARAMETER NAMING ISSUES
Contents
1. You know if I wasn t privy to this discussion and I see the name DOX2 my reaction will be what is DOX1 then or maybe there are 2 oxygen sensors It would not occur to me that it signifies a particular unit That was the problem with User Manual Version 1 where so many codes just did not make sense to an outsider who wasn t privy to the evolution I thought we ve done a very good job of cleaning things up and I d hate to see us go backwards So at the risk of being stoned by the majority I shall continue to advocate sticking with DOXY and promoting the practice of always looking up the units That said I do think we need to think of some bombproof way of alerting users to any format unit changes lt lt lt lt PROFILE lt PARAM gt QC comments removed gt gt gt gt gt Claudia June 21 2004 All gt DOXY DOX2 You know if I wasn t privy to this discussion and gt I see the name DOX2 my reaction will be what is DOX1 then gt or maybe there are 2 oxygen sensors It would not occur to gt me that it signifies a particular unit That was the problem gt with User Manual Version 1 where so many codes just did not gt make sense to an outsider who wasn t privy to the evolution gt I thought we ve done a very good job of cleaning things up Page 8 Mark Ignaszewski Last Updated 9 8 2004 and I d hate to see us go backwards So at the risk of being stoned by the majority I shall continue to advocat2. some hook to link the variable to the instrument from which it derived An solution not requiring any format change is to put TEMP in the lt PARAM gt and use the comment attribute to say temperature from optode sensor 1 This is not so nice because it would require software to take apart this comment if automatic processing is to be done An alternative that would require a small format change is to define another field in the lt PARAM gt definition that allows us to link to information in the float sensor table of the metadata file I think we would also need to add a comment or more rigourously controlled attribute in the SENSOR field to do this properly Though this adds another attribute those with no need for it could just not use it Overall I would prefer something like the second option because it would allow software to readily link the profile to the instrumen that collected it It also preserves the idea of one variable uni one code ct ct 3 I agree 4 The reason I suggested OTMP was that in Canada we already use this to designate a temperature measurement from a electonic oxygen sensor I think it is an optode but you could interpret the O to be other or oxygen as well as optode I agree that we do not want a different code for each instrument TEM2 is as good as any and I will go with the majority My preference for OTMP is to avoid and internal code ma
3. the oxygen sensor so that now there is both a CTD temperature and an optode temperature Our intention was to include this and to pass this temperature profile through the real time QC However we need a code for this We would suggest OTMP with units of degreesC How does this sound Mark Ignaszewski April 9 2004 Bob Thierry and I discussed the extra temperature profile when we were at the AST last month We agreed that the correct course of action was to add a new lt PARAM gt to the standard to accept the data We did not discuss a name at that time but I do not have any problem with the name you have proposed I can not comment on the oxygen units question I have not had time to research it further I would hope that you would report the data in DOXY If the units are equivalent then no conversions will be necessary However if the units are not equivalent I would suggest converting to the standard unit and reporting in DOXY as opposed to using a different new parameter name I will be out of the office next week April 12 16 and will return on 19 April Bob Keeley April 14 2004 Dear Mark Sylvie Following Mark s response we will use OTMP as the code for the temperature derived from the optode oxygen sensor Regarding the use of DOXY I have a complication The code DOXY originated from the GF3 codes and in there the units are millimoles m 3 The Argo manual quotes units of mi
4. ARGO netCDF Parameter Issues Dissolved Oxygen Parameter Names for Additional Parameters There were a couple of attempts to resolve these issues via the DM mailing list There was much discussion but the issue was never decided It is important that the Data Management team reach a final decision at the 2005 Data Management meeting since there are DACs with floats currently in the water that want to start providing these data In the e mail discussions these issues were discussed together with the PROFILE QC discussion I have separated these issues for clarity The PROFILE QC issue will be discussed separately Section C contains a partial compilation of the e mail discussion This can be referenced to see how these proposals were formulated and especially to see the dissenting opinions A Dissolved Oxygen Parameter This part of the proposal seems to be mostly uncontroversial Proposal Parameter Name DOXY no change from current standard Unit Designation micromole kg changed from mmole kg Additional Action Publish the Argo standard conversion algorithms in the Users Manual and ensure that all DACs are converting the units consistently Rationale Parameter Name No change from the current User Manual However there was a proposal to change the name to DOX2 so that users used to the GF3 codes would not be confused by the Argo units of micromole kg There seems to be general consensus that the name DOX2 would cause m
5. STORY PARAMETER Trajectory File TRAJECTORY PARAMETERS HISTORY PARAMETER Meta data File SENSOR PARAMETER 2 When a float has more than one sensor for a given parameter the variable names for the profiles will be lt PARAM gt lt PARAM gt B lt PARAM gt _C etc For example if a float has two oxygen sensors the oxygen profile variables will be DOXY DOXY B Page 2 Mark Ignaszewski Last Updated 9 8 2004 3 When a float has a sensor that measures a secondary parameter the variable names for the profiles will be lt measured PARAM gt lt sensor PARAM gt For example if an oxygen sensor also measures temperature the variable name for the temperature profile measured by the oxygen sensor will be TEMP _DOXY 4 Specific modifications and additions to User Manual Table 3 Parameter Name TEMP DOXY Parameter Long Name SEA TEMPERATURE FROM DOXY SENSOR All other attributes as for TEMP Rationale There is a requirement to store multiple profiles for a given parameter in a single netCDF file The only available option with the current Argo netCDF files is to define a unique variable name for each parameter In the current file definition names are restricted to four characters This would force very cryptic names to be used for these parameters For example DOX1 DOX2 TMP1 TMP2 etc Another option is to allow for longer names that can be more descriptive This option is proposed but there were opinions to the contrar
6. e sticking with DOXY and promoting the practice of always looking up the units VVVV Personally I would prefer DOXY but I do not have old programs that may have a problem due to assumptions about the units Currently we do float DOXY N PROF N LEVELS DOXY long name DISSOLVED OXYGEN DOXY FillValue 99999 f DOXY units mmol kg DOXY valid min 0 f DOXY valid max 650 f DOXY comment In situ measurement DOXY C_ format S9 3f DOXY FORTRAN format MPO LS 3 DOXY resolution 0 001f where mmol micromol not millimol No matter if we decide to stick with DOXY or change to DOX2 I suggest that we change DOXY units mmol kg to DOXY units micromol kg If we decide we have to switch to DOX2 then we should wait until version 3 1 and place an alert into version 2 2 lt lt lt lt PROFILE lt PARAM gt QC comments removed gt gt gt gt gt Annie June 21 2004 I agree with Claudia A No matter if we decide to stick with DOXY or change to DOX2 I suggest that we change DOXY units mmol kg to DOXY units micromol kg Page 9 Mark Ignaszewski Last Updated 9 8 2004
7. fer TEMP DOX2 for the reasons Claudia stated If we understand this correctly then the link between the profile file and the sensor information in the metadata file is is the name of the lt PARAM gt TEMP DOX2 which is the same as SENSOR in the sensor section of the metadata file Anh pointed out that if w xtend the number of characters we use to identify variables we will need to modify the format Specifically in the section on general information about profiles the STATION PARAMETERS field is a STRING4 variable This would need to change The same is true of the PARAMETER field in the calibration part of the profile file as well as the HISTORY PARAMETER of the history section of profiles The same is true for SENSOR field and the PARAMETER field in the metadata file I suppose for consistency we should also look for places where these names are used in the trajectory and technical files and extend the string lengths for them at the same time Shaohua Lin June 17 2004 1 Oxygen unit It was the recommended and accepted at the last Data Management meeting November 2003 that the dissolved oxygen units be changed to micromoles kg We agree that the dissolved oxygen should be micromoles kg In order to be consistent with historical dissolved oxygen data the standard conversion equations for the dissolved oxygen should be published 2 DOX1 and DOX2 Some
8. floats will have two or more oxygen sensors We recommend that the oxygen name consists of 4 characters DOX1 and DOX2 separately represent first and second oxygen sensor If there is one oxygen sensor the mane is DOX1 In this case it can be consistent with names of other parameters and it is not need to change data format descriptions such as Argo profile Page 7 Mark Ignaszewski Last Updated 9 8 2004 format 2 1 and Trajectory format 2 1 It is only need to change Reference table 3 Parameter code table 3 TDO1 and TDO2 The temperature data obtained from oxygen sensors are very important It should be provided in ARGO data We recommend that it be named TDO1 and TDO2 T represents temperature DO1 and DO2 separately represent first and second oxygen sensor Best Regards Bob Keeley June 18 2004 Dear All I was the one pushing to have DOX2 when the oxygen reported was in different units from DOXY I agree with Roy and Annie that it is far better to have the variable name separated from the units but I was worried that people reading the netCDF files would see DOXY and assume units that are used in other files but that may be different units Granted the difference would b vident pretty quickly I argued that naming the variable differently would make the different units obvious lt lt lt lt PROFILE lt PARAM gt QC comments removed gt gt gt gt gt Annie June 18 2004 Hi DOXY DOX2
9. lish a pattern for naming parameters from floats with multiple sensors for a data type RECOMMENDATION 2 Conversion equations Publish the standard conversion equations in the Argo Data Management User s Manual for all unit conversions These standards will be established as the official Argo conversions for all DACs In this case the standard conversion equations for the dissolved oxygen will be published RECOMMENDATION 3 Additional lt PARAM gt variables for data from alternate sensors The oxygen sensors will be able to collect an additional temperature profile New lt PARAM gt names are needed for these data Recommendation TEMP DOX2 indicates it is temperature data collected by the sensor for DOX2 Again this would establish a pattern for naming parameters of this type Page 6 Mark Ignaszewski Last Updated 9 8 2004 The definition for this lt PARAM gt would be the same as for TEMP except Code TEMP DOX2 Parameter long name SEA TEMPERATURE DOX2 SENSOR Comment In situ measurement from oxygen sensor Bob Keeley June 15 2004 Dear All Ahn and I read this Our responses are as follows Recommendation 1 Agree Use DOX2 for oxygen values reported in micromoles kg use DOXY for oxygen reported in millimoles m 3 Agree DOX2_B or more generally lt PARAM gt A B C for multiple sensors Recommendation 2 Agree Recommendation 3 We pre
10. llimoles kg This is not right and these units are not equivalent Those of us using the original GF3 codes have all of our DOXY values in our archives recorded in millimoles m 3 To introduce a different unit for the Page 4 Mark Ignaszewski Last Updated 9 8 2004 same code is going to cause grief Since it is early in the float oxygen game we should be able to correct the units of DOXY in the Argo manual with no great problem Otherwise we need to change the name of DOXY for Argo to be something else with units of millimoles kg Bob Keeley May 07 2004 Dear All Here are my responses to Mark s questions 1 Okay 2 The question really is how to store measurements of the same variable in the same units and perhaps from the same instrument in a single netCDF or archive file To help clarify the discussion assume we have a temperature from the CTD 2 temperatures from 2 oxygen probes as well as salinity and pressure The codes that we use to designate the variable measured have by convention the units built in hence the discussion surrounding DOXY and DOX2 But in this case all of the temperature sensors report in the same units In the netCDF file we could have three lt PARAM gt s all being TEMP This is perfectly good except I think we want to associate the profile with the instrument The quick solution for temperature from an oxygen sensor is to choose a different code as we did An alternative is to have
11. ore confusion than it would solve The units are included in the Argo netCDF data files and users should use this information Unit Designation The current unit designator is mmol kg there is an ambiguity in the meaning of the prefix m Spelling out the prefix micro seems like a good idea Page 1 Mark Ignaszewski Last Updated 9 8 2004 B Names for Additional Parameters This was the controversial part of the previous proposal and the following proposal is being submitted for consideration Alternate opinions are included in section C below The Data Management team MUST decide this issue at the 2005 meeting The first three items under Proposal are general proposals to deal with this issue as new cases are encountered The fourth item addresses the immediate and overdue needs for floats already in the water Proposal 1 Change the allowed length of parameter names from STRING4 to STRING16 The list of affected variables is below The allowed parameter names lt PARAM gt will still be defined in Table 3 of the User s Manual The names already in the table will not change and will continue to be the preferred names o Important Note The DACs can implement this change incrementally There is no reason for each DAC to reprocess their files or to have all of the changes synchronized Only those DACs needing the longer names would need to change initially AFFECTED VARIABLES Profile File STATION PARAMETER PARAMETER HI
12. pping issue in Canada if I can lt lt lt lt lt lt The following e mail was the proposal that after refinements suggested by others became the current proposal gt gt gt gt gt gt Page 5 Mark Ignaszewski Last Updated 9 8 2004 Mark Ignaszewski June 14 2004 Hello All Some issues regarding the DOXY variable have been raised The Data Management team needs to make some decisions so we can move forward with getting the dissolved oxygen data and other parameters associated with the oxygen sensors distributed on the GDACs Please review these comments and respond Floats with these new data are already in the water We need to move forward with these changes very soon Thank you in advance for your help with these issues NOTE These issues will NOT require a big format change like w xperienced in February RECOMMENDATION 1 Oxygen lt PARAM gt name It was the recommended and accepted at the last Data Management meeting November 2003 that the dissolved oxygen units be changed to micromoles kg However the nam DOXY originated from the GF3 codes and is associated with the units of millimoles m 3 A name change in the Argo files is recommended to prevent confusion with this historical name and unit The new recommended lt PARAM gt name is DOX2 Some floats will have two oxygen sensors The recommendation for the second oxygen lt PARAM gt is DOX2_B This will estab
13. y see section C below There are two distinct cases 1 a float has more than one sensor for a given parameter and 2 a float sensor measures a secondary parameter that is also measured by another sensor The proposed naming convention makes these two cases distinct The two examples above illustrate the difference and will likely be the first actual uses NOTE It is assumed that all parameters will be on the same pressure levels Page 3 Mark Ignaszewski Last Updated 9 8 2004 C Comments of the Data Management Members I could not realistically include all of the e mails received regarding these issues there were almost 50 messages What I have tried to do is organize some of the relevant e mail traffic to stimulate further discussion I have specifically included all dissenting opinions to highlight the thoughts of those that disagreed with the proposal lt lt lt lt The next three messages started this whole discussion The proposal similar to the above was sent to the mail list on June 15 2004 gt gt gt gt gt Bob Keeley April 8 2004 Dear Sylvie Mark We are expecting to deploy a new Apex float equipped with an oxygen sensor later this month I think I need some new codes for the variables So the oxygen vales are reported in units of micromoles 1 which we think is equivalent to millimoles m 3 assuming lcc 1ml So is it okay to use DOXY for the reported oxygen Second there is an additional temperature sensor with
Download Pdf Manuals
Related Search