Structure

Dimensions

The NetCDF files used in the system follow a very tight structure. Each file has exactly five dimensions defined. When the file is initially empty, the dimension section might look like

  netcdf diagnostic {
  dimensions:
      lon = 1 ;
      lat = 1 ;
      depth = 1 ;
      time = UNLIMITED ; // (0 currently)
        

Data Variables and Quality Control

Each variable that is not a coordinate variable also has its own quality control variable. Shown below is the example of air_temperature

float air_temperature(time, air_temperature_depth, lat, lon) ;
    air_temperature:long_name = "Air Temperature" ;
    air_temperature:standard_name = "air_temperature" ;
    air_temperature:grib_code = "11 E 130" ;
    air_temperature:short_name = "AT" ;
    air_temperature:scale_factor = 1. ;
    air_temperature:add_offset = 0. ;
    air_temperature:_FillValue = -999.f ;
    air_temperature:units = "celsius" ;
    air_temperature:valid_range = -40.f, 40.f ;
    air_temperature:is_dead = 2452774.125 ;
    air_temperature:sensor_depth = -3. ;
    air_temperature:epic_code = 20 ;
byte air_temperature_qc(time, air_temperature_depth, lat, lon) ;
    air_temperature_qc:long_name = "Air Temperature QC" ;
    air_temperature_qc:short_name = "ATQC" ;
    air_temperature_qc:scale_factor = 1. ;
    air_temperature_qc:add_offset = 0. ;
    air_temperature_qc:_FillValue = -128b ;
    air_temperature_qc:units = "none" ;
    air_temperature_qc:valid_range = -127s, 127s ;
    air_temperature_qc:sensor_depth = -3. ;
    air_temperature_qc:flag_values = 0b, 1b, 2b, 3b ;
    air_temperature_qc:flag_meanings = 0b ;
        

The long_name, _FillValue, units, and valid_range attributes are all NetCDF standards and are strictly adhered to. The scale_factor and add_offset, attributes aren't really needed here, as they imply packed data. The is_dead is a flag that specifies if and when a datastream becomes corrupt. It remains zero if the datastream is ok. For example, if the sensor that measures air_temperature goes bad on November 22, 2001, the is_dead attribute will be changed from 0 to the julian date for November 22, 2001 (2452236).

The standard_name is part of the CF standard, and is applied where possible. It is a requirement that the time and depth dimensions always have the standard_name attribute set.

The quality control variable also has attributes that describe its possible values. Zero ALWAYS means that the associated datum is good. Any other values means that the data is questionable and those values are to some extent described in the attribute list.

Global Attributes

A typical listing of NetCDF global attributes might look like

  // global attributes:
  :Conventions = "COARDS" ;
  :institution = "Department of Physical Oceanography, School of Marine Sciences, University of Maine" ;
  :institution_url = "http://gyre.umeoce.maine.edu" ;
  :project = "GOMOOS" ;
  :project_url = "http://gomoos.org" ;
  :contact = "nealp@maine.edu,ljm@umeoce.maine.edu,jevans@umeoce.maine.edu" ;
  :time_zone = "UTC" ;
  :julian_day_convention = "Julian Day Number 0 starts at 00:00 UTC on 25 November 4713 BC" ;
  :instrument_type = "fsi" ;
  :instrument_number = 0 ;
  :processing = "raw" ;
  :water_depth = 110. ;
  :mooring_site_id = "A0101" ;
  :mooring_site_desc = "Massachusetts Bay" ;
  :history = "Created on Wed Apr 11 17:56:05 EDT 2001 by jevans" ;
  :breakout_id = 3;
  :delta_t = 60;
        

• Conventions . It is considered good form to list the NetCDF conventions followed. We have chosen [ CF ] .

• institution . Optional, name of the institution where created.

• institution_url . Optional, web site address of institution.

• project . Always GOMOOS.

• project_url . Optional, GoMOOS web site URL.

• contact . Optional, email addresses of contacts for buoy personnel.

• time_zone . Optional, time zone upon which ``time'' data is based.

• julian_day_convention . Optional, describes how julian days work.

• buffer_name . Required. Describes the instrument. Example would be doppler.

• instrument_number . Required. This helps to discriminate multiple identical instruments on a buoy. For example, there are usually three SBE37s on a buoy, which are given instrument_number ids of 0, 1, and 2. One might think that sensor depth would be enough to discriminate, but there is also the possibility of multiple instruments at the same depth.

• processing . Required. This should be one of

  • raw

  • goes-raw

• water_depth . Required. Depth of water column at deployment position.

• mooring_site_id . Required. This is always a five character code, where the first character is an alphabetical character that specifies a region. The second and third characters specify a position within that region, and the fourth and fifth characters specify a particular deployment at a particular position. So, for example, ``F0102'' pertains to region ``F'', the first position in that region where a buoy was deployed, and the second deployment for that position.

• mooring_site_description . Optional. A short description of the particular size where the mooring was deployed.

• history . Optional, but highly recommended for all NetCDF files. Contains a history of processing steps.

• breakout_id . Required for raw processing files. Each instrument type translates into a specific numeric value that is used to split out its particular data stream from the aggregate stream returned by the campbell logger.

• delta_t . Required. Specifies how many minutes between datums. Most of the time this is 60.