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.

Change history (0)

Note: See TracTickets for help on using tickets.