1 / 13

Argo format and CF compatibility

Argo format and CF compatibility. OceanOBS09

amil
Download Presentation

Argo format and CF compatibility

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Argo format and CF compatibility • OceanOBS09 • Strengthen and enhance the international framework under GCOS, GOOS, WCRP, IGBP and supporting regional and national frameworks for sustained world ocean observing and information systems supporting the needs of society about ocean weather, climate, ecosystems, carbon and chemistry • A strong message on data management : NetCDF and CF compatibility will enhance data sharing and use. • The Argo data format is an implementation of NetCDF by the Argo community. • Initiated in December 2001 • Version 1.0 adopted in July 2002 • CF-1.0 convention became available in October 2003

  2. CF metadata convention • NetCDF Climate and Forecast (CF) Metadata Conventionhttp://cf-pcmdi.llnl.gov/ • The conventions for climate and forecast (CF) metadata are designed to promote the processing and sharing of files created with the NetCDF API • The CF conventions define metadata that provide a definitive description of what the data in each variable represents, and the spatial and temporal properties of the data. • This enables users of data from different sources to decide which quantities are comparable, and facilitates building applications with powerful extraction, regridding, and display capabilities.

  3. Argo implementation of CF ? • Can we implement CF compatibility without breaking down the data management ? • Probably Yes : if we enrich the existing format, with global attributes and more parameter attributes. • CF does not standardize NetCDF variable names.It standardizes some attributes of NetCDF variables.

  4. Status of the existing profile format • CF file checkerhttp://titania.badc.rl.ac.uk/cgi-bin/cf-checker.pl CHECKING NetCDF FILE: /tmp/D69001_010.nc ===================== Using CF Checker version 1.4.0 Using Standard Name Table Version 12 (2009-07-06T12:05:02Z) Using Area Type Table Version 1 (5 December 2008) WARNING (2.6.1): No 'Conventions' attribute present ------------------ Checking variable: DATA_TYPE WARNING (3): No standard_name or long_name attribute specified ------------------ ... ------------------ Checking variable: TEMP … ERRORS detected: 0 WARNINGS given: 9

  5. Addition needed for a CF-1.4 compatibility • Can be done in 3 steps • Add a global attribute section • Add a long name to all variables • Add a standard name and X, Y, Z, T axis attributes to physical parameters • Step 1 : add a global attribute section // global attributes: :data_type = "Argo vertical profile" ; :format_version = "2.2"; "2.3" ? :user_manual_version = "2.3" ; :Conventions = "CF-1.4" ; • Step 2 : add a long name attribute to all variables char DATA_TYPE(STRING16) ; DATA_TYPE:long_name = "Data type" ;

  6. Addition needed for a CF-1.4 compatibility • Step 3 : add standard_name and axis attributes double JULD(N_PROF) ; JULD:long_name = "Julian day (UTC) of the station relative to REFERENCE_DATE_TIME" ; JULD:standard_name = "time" ; JULD:units = "days since 1950-01-01 00:00:00 UTC" ; JULD:conventions = "Relative julian days with decimal part (as parts of day)" ; JULD:_FillValue = 999999. ; JULD:axis = "T" ;

  7. Addition needed for a CF-1.4 compatibility • Step 3 : add standard_name and axis attributes double LATITUDE(N_PROF) ; LATITUDE:long_name = "Latitude of the station, best estimate" ; LATITUDE:standard_name = "latitude" ; LATITUDE:units = "degree_north" ; LATITUDE:_FillValue = 99999. ; LATITUDE:valid_min = -90. ; LATITUDE:valid_max = 90. ; LATITUDE:axis = "Y" ; double LONGITUDE(N_PROF) ; LONGITUDE:long_name = "Longitude of the station, best estimate" ; LONGITUDE:standard_name = "longitude" ; LONGITUDE:units = "degree_east" ; LONGITUDE:_FillValue = 99999. ; LONGITUDE:valid_min = -180. ; LONGITUDE:valid_max = 180. ; LONGITUDE:axis = "X" ;

  8. Addition needed for a CF-1.4 compatibility • Step 3 : add standard_name and axis attributes float PRES(N_PROF, N_LEVELS) ; PRES:long_name = "SEA PRESSURE" ; PRES:standard_name = "sea_water_pressure" ; PRES:_FillValue = 99999.f ; PRES:units = "decibar" ; PRES:valid_min = 0.f ; PRES:valid_max = 12000.f ; PRES:comment = "In situ measurement, sea surface = 0" ; PRES:C_format = "%7.1f" ; PRES:FORTRAN_format = "F7.1" ; PRES:resolution = 0.1f ; PRES:axis = "Z" ; float TEMP(N_PROF, N_LEVELS) ; TEMP:long_name = "SEA TEMPERATURE IN SITU ITS-90 SCALE" ; TEMP:standard_name = "sea_water_temperature" ; TEMP:_FillValue = 99999.f ; TEMP:units = "degree_Celsius" ; TEMP:valid_min = -2.f ; TEMP:valid_max = 40.f ; TEMP:comment = "In situ measurement" ; TEMP:C_format = "%9.3f" ; TEMP:FORTRAN_format = "F9.3" ; TEMP:resolution = 0.001f ;

  9. We can do more with CF… as OceanSITES does • We can take advantage of CF possibilities to handle rich description for complex parameters such as Oxygen and bio-geo-chemical parameters. float DOXY(N_PROF, N_LEVELS); DOXY:standard_name = “sea_water_dissolevd_oxygen”; DOXY:units = "micromole/kg"; DOXY:_FillValue = 99999.f ; DOXY:long_name = "sea water dissolved oxygen"; DOXY:valid_min = 0.f; DOXY:valid_max = 650.f; DOXY:comment = "in situ measurement"; DOXY:C_format = "%9.3f "; DOXY:FORTRAN_format = " F9.3"; DOXY:resolution = 0.01; DOXY:ancillary_variables = “DOXY_QC,DOXY_ADJUSTED,DOXY_ERROR” ; DOXY:uncertainty = 0.2; DOXY:accuracy = 0.1; DOXY:precision = 0.1; DOXY:resolution = 0.01; DOXY: cell_methods = “median”; DOXY:reference_scale = “???”

  10. We can do more with CF… QC flags char TEMP_QC(N_PROF, N_LEVELS) ; TEMP_QC:long_name = "quality flag" ; TEMP_QC:conventions = "Argo reference table 2" ; TEMP_QC:_FillValue = " " ; TEMP_QC: flag_values = "0,1,2,3,4,5,7,8,9" ; TEMP_QC: flag_meanings = "no qc, good, probably good, probably bad,bad,value changed,interpolated value,missing value" ;

  11. How to handle more parameters • Add new entries in :Reference table 3: parameter code table • Remark on duplicate sensorsSome floats are equipped with 2 different sensors, measuring the same physical parameter. In that case, add the integer "2" at the end of the code of the duplicate parameter (e.g. DOXY2).If more sensors that measure the same physical parameter are added, then the integer will simply increase by 1 (i.e. DOXY3, DOXY4, and so on). • Use “ancillary_variables” attributes to identify relations between different parameters.Example :DOXY:ancillary_variables = “DOXY_QC,DOXY_ADJUSTED,DOXY_ERROR” ;

  12. How to handle more parameters Vertical reference issue • If parameters have different vertical reference, a proposal is to handle one profile per vertical reference. • Example : 2 CTD sensors on a float • Temperature from CTD12000 dbar to surface in 70 levels • Temperature from CTD250 dbar to surface in 100 levels • We have 2 profiles, the profile from CTD2 is profile N°2Add a cycle_profile_number equal to 2

  13. How to handle more parameters • Bouncing files : a float can perform more than 2 profiles per cycle : • Add a cycle_profile_number

More Related