Area codes missing from WMO routing headers

[Dave Offiler]

While investigating why CHAMP data apparantly not being recieved by Meteo-France via GTS, Duncan Jeffrey (FROST admin) reported that some geographical area designators (A,E,I) have never been seen for CHAMP (routing headers "IUT[A-L]14 EGRR").

Area 'A' is 0-90W, 30-60N and would be expected to have many occultations per day. It seems more likely that the ARHs are not being correctly generated from the observation lat/lons. Further, since designators A,E,I are all 0-90W, this points to a longitude sign or range problem.

The ROPP encoder calls GTSHDRS() from the BUFR extras package; this routine has been well validated and is used for other data types, so the problem is most likley in the ROPP encoder itself.

The Area code in the ARH can in principle be used to filter observations to particular (large) geographic zones, but current users are all in global models and can be assumed to want all data. Hence this is not a show-stopper and can be corrected as part the next update release.

[Dave Offiler]

Correction: area 'A' is 30-90N. Also, severity incorrectly set as 'blocker' - should have been 'normal'

Problem traced; on conversion from ROPP to BUFR-standard in the Values array, the profile nominal longitude is forced into the range +/-180degrees. The lat/lon values are later extracted form this array (elements 30,31) and passed to the GTSHDR() subroutine (as NINT'd values). GTSHDR() actually requires longitudes in the range 0-359deg.

Code in ropp2bufr - subroutine EncodeBUFR() - amended to ensure this range is passed to GTSHDR(). Committed as [1178] (and [1179] to clear a typos causing a run-time crash plus code to write out the generated ARH with -d when using any -g option).

[Also amended the code in GTShdr() (in the MetO BUFR package) to accept a range +/-180 or 0-360

• built as release 16.6 - but the ropp2bufr change is backward compatible with previous releases of the BUFR library package.]

Re-built all 3rd party dependency libraries (including BUFR v16.6) and all ROPP code with latest Intel ifort v9.1.

Tested using a CHAMP-GFZ profile located at 49.8N, 57.8W, which now correctly codes A2 as 'A' (previous build coded as 'D')

[(none)]

Milestone 1.1 deleted