need bounds coordinate variable in netCDF files with bounds attribute

[karlmsmith]

Reported by @AnsleyManke on 11 Mar 2005 19:13 UTC The CF standard defines bounds for irregular axes as a dimension of 2. Here is an example for a latitude axis from the CF Conventions:

---

dimensions:
  lat = 64;
  nv = 2;    // number of vertices
variables:
  float lat(lat);
    lat:long_name = "latitude";
    lat:units = "degrees_north";
    lat:bounds = "lat_bnds"; 
  float lat_bnds(lat,nv);

The boundary variable lat_bnds associates a latitude gridpoint i 
with the interval whose boundaries are lat_bnds(i,0) and lat_bnds(i,1). 
The gridpoint location, lat(i), should be contained within this 
interval.

---

LAS sees the dimension on the latitude coordinate variable, but it needs the bounds variable itself to be fully defined as a coordinate. We need to define the bounds coordinate (nv above) and give it data coordinate values of 1,2

dimensions:
  lat = 64;
  nv = 2;    // number of vertices
variables:
  float lat(lat);
    lat:long_name = "latitude";
    lat:units = "degrees_north";
    lat:bounds = "lat_bnds"; 
  float lat_bnds(lat,nv);
  float nv(nv);
     nv:point_spacing = "even" ;

...

data:

bnds = 1, 2 ;

Martin Schmidt reported this, and for a z axis, he reports that nv also needs a

     nv:positive= "up" ;

Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1196

[karlmsmith]

Comment by @AnsleyManke on 25 May 2005 18:11 UTC fixed in cd_write_bndsdim, cd_write_axis, cd_write_defer_coord.

[karlmsmith]

Comment by @AnsleyManke on 14 Jun 2005 19:50 UTC For a z axis, we do NOT want to use this attribute for the bounds vertices:

     nv:positive= "up" ;

For a z axis, the bounds vertices cannot be in the Z direction. The bounds themselves are in Z, and so the vertices should be perpendicular to the z axis. If we put positive="up" then Ferret interprets the vertex variable as being in the Z direction and we cannot have two z axes on a variable. Therefore we do NOT want nv to have a positive="up" attribute.

---

dimensions:
  dep = 64;
  nv = 2;    // number of vertices
variables:
  float dep(dep);
    dep:units  = "meters";
    dep:bounds = "dep_bnds"; 
    dep:axis   = "Z";
  float dep_bnds(dep,nv);
  float nv(nv);
     nv:point_spacing = "even" ;

...

---

If there is also nv:positive="up"; on nv, then Ferret returns: NOTE: unsupported ordering of axes in variable dep_bnds NOTE: The default ordering will be used.

and dep_bnds is of dimension i=1:2, j=1:ndepths.

---

This says that if we have a 4-D variable, all having irregular axes, we will need more than one coordinate variable for the vertices of the bounds variables. bnds cannot have more than one direction in a file.

[karlmsmith]

Comment by @AnsleyManke on 5 Jul 2005 23:10 UTC We are not going to change the behavior as originally implemented, with the bounds being a coordinate but NOT a fully defined variable. Stay with the CF standard, under bounds, http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html#bnds

and see also the example in that section, "methods applied to a time series" for example nc headers. Martin reports that he had previously had a problem with addXML and a file having bounds, but Roland tested the example file that Martin pointed us to with the new addXML tool and it works fine.

[karlmsmith]

Comment by @AnsleyManke on 8 Dec 2005 17:15 UTC 12/8/2005 Martin Schmidt writes with further comments on incompatible implementation of bounds coordinates in the MOM code's netcdf reading vs Ferret's implementation.

Martin Schmidt wrote:

Hi,

I send this mail to the mom4 and ferret list, because there is a possible incompatibility in the understanding of netcdf in ferret and mom4 (fms).

Trying to read netcdf-files through the data_override utility I have found the following:

• ferret is a useful tool to process netcdf-files. Recent versions add bounds, if axes are non equidistant. This is a nice feature as far as information on data is kept accurate.

Ferret adds a dimension bnds to the netcdf-file and defines a double variable like in the example LON = 44 ; LAT = 38 ; bnds = 2 ; TAX = UNLIMITED ; // (1714 currently) double LAT(LAT) ; LAT:units = "degrees_north" ; LAT:point_spacing = "uneven" ; LAT:axis = "Y" ; LAT:bounds = "LAT_bnds" ; double LAT_bnds(LAT, bnds) ;

There is no axis named bnds!

• mom4 tries to read bounds too. However, it expects a complete axis. In mpp_read_meta the number of dimensions is read and then axes are allocated:

  allocate(Axis(ndim))

However, the axis corresponding to the dimension bnds is not there and remains unknown. Later in get_axis_bounds, mom4 gets confused. It finds bounds in the attribute list of one axis and tries to extract the values from a data structure, which has the type of axis. However, there is no axis but a field. Mom4 falls back to the default axis (nothing), gets the axis length -1 which gives an error stop.

Hence, two important codes, Ferret and MOM4 (FMS) make different assumptions on the "correct" structure of a netcdf File. Please note, also LAS 6.4 fails with netcdf-files with bounds from ferret.

I put this on the two list to draw developers attention to this problem.

Kind regards, Martin Schmidt