Opened 14 years ago
Last modified 14 years ago
#215 closed defect
Default BUFR ARH? — at Initial version
Reported by: | Dave Offiler | Owned by: | Dave Offiler |
---|---|---|---|
Priority: | minor | Milestone: | 4.1 |
Component: | ropp_io | Version: | 4.0 |
Keywords: | BUFR, abbrevaited routing headers, ARH | Cc: |
Description
Rune has been testing the DRI Candidate Release v4.1 and reports an anomoly in the v4.1 ropp2bufr tool wrt the currently operational v3.0 version:
I've run the GRAS SAF production on a days occulatations using ROPP-3 and ROPP-4.1 . The are some differences in the output netcdf files that I guess is due to going from float to doubles. I've tried to compare output bufr files generated using ropp2bufr using input netcdf ('dis'-)files. When I run the old ropp2bufr on both the old and new dis-files there is no difference between the output bufr files. It is the same when I run the new version on both files. But the bufr output files of ropp2bufr version 3,0 and the ropp2bufr version 4.1 doesn't compare well. Looking at the binary dump it seems that the GTS header data is now added as default ? I can see the 'IUTL14 EKMI 050812' header in the bufr output files.
The intent is that -g or -gi switches are required to generate any abbreviated routing header (ARH) (default: no ARH generated), and -c nn (nn=BUFR code for originating centre) to set the ICAO code in the header (default nn=74 for 'EGRR').
So code needs checking to see why this non-default default ARH is being generated. From memory I don't recall any deliberate change to the way headers are generated between v3.0 and v4.0, and onlt DateTime changes have been made to v4.1.
Since the ARH Rune quotes are correct and required for operational BUFR, this is consisderd a minor anomoly, though ought to be closed for v4.1 release.