POD missing from BUFR

[Dave Offiler]

While setting up reflections flagging for Estel's test data - which involves decoding the UCAR BUFR files to netCDF (bufr2ropp) and re-encoding to BUFR (special version of ropp2bufr which hard-sets the PCD reflections flag), and a validation by comparing decoded dumps of the UCAR and flagged BUFR - I found (for the tested case) that both GPS and LEO POD (pos+vel) were missing from the flagged BUFR but present (or at least not obviously fill values) in the original. The overall refractivity quality index parameter was similarly missing (zero in the original). As these don't affect Sean's use of the BUFR for assimilation trials, I just continued with the processing.

Both bufr2ropp & (modified) ropp2bufr tools are from the current trunk [2443] (essentially v4.0)

The intermediate netCDF file needs checking to see whether these parameters are present or missing, which will inform as to whether it is the decoder or encoder at fault. Or even if the original values are invalid. Inappropriate valid range might explain the POD going missing, but unlikely for the Ref.QI.

[Dave Offiler]

Not an issue for operational processing (CDAAC do their own BUFR conversion and GFZ files do not contain POD info) and as far as we are aware, no-one currently requires this POD information. Therefore changing the milestone to 5.0.

[Dave Offiler]

Confirmed with a recent UCAR C/NOFS BUFR file that contains valid POD values that the POD data does not get written to the output netCDF file by bufr2ropp.

Traced this to ropp_io_rangecheck(), where SNR+Phase were being checked (and npoints set to zero if all missing) before a similar check for POD. Since BUFR contains no SNR or phase, npoints was set to zero and the POD check was being skipped.

Modified to check all SNR+Phase+POD in one go, and only set npoints to zero if all missing.

Re-tested with C/NOFS BUFR file, and Level 1a data (single sample, SNR+Phase 'missing', correct POD values) now present in the netCDF.

Since ropp_io_rangecheck() is a basic routine, this change needs to be more extensively tested than this single BUFR use-case.

Also, not sure what I meant by overall refractivity quality index parameter so this still needs checking.

Current POD change checked in as [2805], but leaving this Ticket open for now.

[Dave Offiler]

Performed a bufr2ropp & ropp2bufr cycle on the sample UCAR C/NOFS & SAC-C BUFR files and dumped decodes from all 4 BUFR files using decbufr tool.

Since UCAR encode Ed.3 and ROPP-5 is now Ed.4, plus some other Section 1 parameter value updates, differences in the headers are detected, and all are as expected. More importantly, the Section 4 part (user data) pairs were completely identical.

This confirms that (a) POD is now correctly decoded and re-encoded and (b) there are no other parameters going missing.

Closing this ticket.