Updates to BUFR Section 1

[Dave Offiler]

Decisions taken at the first meeting of the INTER-PROGRAMME EXPERT TEAM ON DATA REPRESENTATION AND CODES (Geneva, 15 - 18 September 2009) - see ​http://www.wmo.int/pages/prog/www/ISS/Meetings/IPET-DRC_Geneva2009/IPET-DRC_DocPlan.html has knock-on consequences for the ROPP BUFR encoder.

Specifically, these affect the details encoded into BUFR Section 1 via the ropp2bufr tool in ropp_io:

a) Local Table Version Number

Octet 12 in BUFR Edition 3 (Octet 15 in Ed.4) is clarified to be encoded as zero when there are no local descriptors being used (i.e. all descriptors are from the Master Table).

Currently, ropp2bufr has a hard-coded value of '-99' which (supposedly) indicates the default value, to be actually set by the MetDB encoder routine enbufv2(). According to the comments in this latter routine, the default is '0' (as expected), but -99 is not actually tested (as some other defaults are), and the encoded value is not defined; in practice, it seems to be encoded as '1'. This bug has been notified to the MetDB team.

When GFZ started using ropp2bufr for CHAMP & GRACE-A, sending the BUFR files to DWD for insertion onto the GTS/RMDCN, DWD actually insisted that '0' was anyway incorrect, and '1' was the correct value, so it was left like that.

On the other hand, Milan Dragosavac (ECMWF) believes that when no local tables are being used, this octet should be coded as '255'.

The IPET clarifies that '0' is the correct value in these circumstances, so VerLocTable in ropp2bufr should be hard-coded as '0' to work-around the MetDB bug noted above.

Since this value is used to build the ECMWF decoder look-up table file names, users must be given due warning before this change is implemented for GTS/RMDCN dissemination.

b) Data Sub-Category

The 2008 BUFR Tables mini-update introduced several sub-categories to Common Code Table C-13 (which is used in conjunction with Table A) for Octet 12 in Edition 4. This octet defines an 'International data sub-category' Amongst the new entries for Data category 3 (Satellite Sounding) is GPSRO with a code value 50, tagged 'awaiting validation'.

For BUFR edition 3, octet 10 (and octet 13 in Ed.4) is a locally-defined data sub-type. This is currently encoded as 255 (implying unknown/missing) in ropp2bufr. This octet, not having had any special value thus far, should be encoded as 50, and this value also adopted for Octet 13 for a future Ed.4.

While this code change will alter the value encoded in Section 1, as far as we are aware, no use is made of it today. However, notice to users should be given at the same time as for change (a).

c) Master Table Version Number

Not an IPET issue, but ropp2bufr uses -99 for the (default) master table version. The current v18 MetDB enbufrv2() routine substitutes '13', but this is liable to change with future library releases having updated BUFR tables. Advice now is that this value should be fixed unless the Table D sequence, or any Table B element is changed for the data being encoded, which would then warrant an updated table version number.

Hence VerMasTable in ropp2bufr should be hard-coded as '13' in place of '-99'.

This code change will not alter the value actually encoded into BUFR Section 1, but merely fix the current value until explicitly changed within the app.

d) Master Table

Currently, ropp2bufr codes Master Table as -99, again for enbufv2 to convert - in this case to '0' for 'meteorology'. This should be hard-coded to '0' for future compatibility with the ECMWF BUFR library which does not employ such defaults.

This code change would not alter the value actually encoded into BUFR Section 1 currently.

All of the above changes should also be implemented when portign to the ECMWF BUFR library (see Ticket #177)

[Dave Offiler]

a) Changed ropp2bufr Section 1 hard-coded values as above.

b) Rebuilt application (configure/build system changed to use libmetdbbufr.a instead of libbufr.a with additional diagnostic text if library not found. Ideally, the buildpack script should rename MetDB libbufr.a if libmetdbbufr is not present. This change for future compatibility with ECMWF library)

c) Encoded data/ropp_test.nc, then decoded resulting BUFR file headers with generic decbufr tool to confirm expected Section 1 values.

d) Generated new BUFR reference file (and decoded netCDF reference file) in data/ and run /tests/t_roppbufr successfully.

Checked in as changeset [2268].