L1 and L2 data in bufr

[Huw Lewis]

Email from Stig (17 Oct 2008)

Hi Dave,

Looking closer at the BUFR files from the thinner test that we ran a 
couple of weeks ago (ascii output of it), I see that there are -9999.9 
for L1 and L2 BAs and IPs, only for the iono-free BA and IP there are 
values. In our netCDF, from which Martin used ropp2bufr, there are 
values in  L1 and L2 fields. So we concluded that it may be the 
ropp2bufr that does not put in those values. Would you be able to 
confirm this? Is this intentional that ROPP does not put L1 and L2 data 
in BUFR?

-Stig

Requires investigation and an explanation

[Dave Offiler]

Huw has checked some sample GRAS files from the DMI server, and cannot reproduce this problem.

Stig has now provided sample netCDF (in and out) and the intermediate BUFR file in which L1 & L2 go missing; again we cannot reproduce the problem using the same input netCDF file.

Further investigation of these sample files (using the BUFR decbufr generic decoder tool) show that the DMI BUFR file contains only the Lc BA/IP values and no L1 or L2 profiles (note: No L1 or L2 profiles at all, not that the BA values are merely encoded as 'missing’). Hence we can rule out the bufr2ropp decoder and concentrate on ropp2bufr.

Not encoding any L1/L2 profiles might be due to:

• The –l switch being used with ropp2bufr (ie force encoding of Lc only). Stig claims this switch was not used.

• All L1 & L2 BA and/or IP values being set missing during the pre- or post-thinning range checking stage. The pre-BUFR checks may then perform as if the –l switch were present. This would imply that Lc BA/IP are nominal and all L1/L2 BA/IP are out-of-range (the same range limits are applied to all BA/IP types).

• All L1/L2 BA/IP values are being set missing somewhere else, where they shouldn't be - e.g. during the thinning process.

In all, cases, the decoder would effectively re-create default L1/L2 (missing data) profiles in the output netCDF.

As the same input file encodes and decodes the L1 & L2 BA/IP profiles normally with the local MetO ROPP-2 tools, further investigation is needed with Martin (away when this issue was raised) to determine what could be different between the MetO and DMI builds and exactly were the L1/L2 data is going AWOL.

This issue needs resolving before release (or DMI use ROPP-2 operationally), so really should be fixed or at least explained before DRI.

This issue is noted in the first draft ROPP-2 Beta Test Report.

[Huw Lewis]

On a visit to DMI (for ROPP-2 DRI) Huw looked at this issue with Martin.

It became apparent that the thinner tests which Stig was looking at were generated using ropp2bufr with the '-l' flag set. This explicitly forces only LC data to be encoded. So, there was not a problem with the ROPP software, just some mis-understanding of how the routines were implemented.

Note that the GRAS SAF NRT chain would not have been run using the '-l' flag, so the GRAS SAF products contain L1 and L2 data.

Ticket closed as 'fixed' as we have now investigated the problem, and understood the reasons for the behaviour noticed at DMI.