Lower BA range in BUFR?

[Dave Offiler]

The BUFR template document defines the BA descriptor with an offset and bit width which is capable of holding a minimum BA value of -10-3 rad. However the current trunk code ropp2bufr.f90 has a hard-coded check limit of -10-4.

The default ROPP value (in ropp_io_types.f90) is -10-3, (though there is not 100% correlation between internal ROPP and BUFR range limit values (mostly due to limitations of the BUFR format).

Since this document & code and ranges in general have been reviewed several times since ROPP was first released, there must have been some good reason why the coded value is different from the template (though I have no recollection now what that reason might have been!) The -10-4 value is certainly a safe option.

Stig reports that DMI have changed the coded value to -10-3 with no ill effects (is this used operationally?)

I've changed the coded value in trunk version of ropp2bufr.f90 to -10-3, re-built the executable and tested with the tests/t_ropp2bufr script. This shows a PASS, with no differences in the BUFR file from the reference file created with the previous (-10-4) version. This merely says that there are no BA values in the test file within the range -10-3 to -10-4, so this is not a rigorous test of the change.

Leaving this ticket open until it is confirmed that the change has no bad effects within ropp2bufr itself, bufr2ropp or any other tool, using at least one input file with appropriately low BA values.

[Dave Offiler]

Committed change as #2679. Still needs more rigorous testing.

[Dave Offiler]

Stig has provided a test file atm20101209_140409_M02_1270399559_N0018_XXXX.nc which contains 4 BA values lying between -10-4 and -10-3 (with 1097 BA values smaller than -103 [missing data]).

In the following analysis, v4.1 refers to the public v4.1 release and v4.1-1 to the patched (#2629) version of ropp2bufr (from the Version strings output by the -v command line switch)

1) Running ropp2bufr v4.1 and v4.1-1 and bufr2ropp (v4.1) on each resulting BUFR file shows no reported problems.

2) Dumping both re-created netCDF files to cdl with ncdump confirms that the 4 critical values are set missing with v4.1 and are preserved with v4.1-1.

3) Running decbufr on each BUFR file outputting to a dump file and inspecting the diffs shows that the 4 critical values were set missing in the 4.1 conversion, but retain correct values for the 4.1-1.

Apart from the 4 affected values, all other elements are unchanged (apart from expected differences in the netCDF headers involving files names or timestamps).

Given that DMI have made this patch locally and tested on many files, this test is considered to be sufficient evidence that the same change in the trunk version works as intended. This ticket is hereby closed.