PCD wrong in bufr2ropp

[Ian Culverwell]

The quality flags in (for example) the attached BUFR files are being incorrectly mapped to the ROPP variable 'PCD' by bufr2ropp. Eg:

unix> file=GRAS_1B_M02_20140101000329Z_20140101000436Z_R_O_20140709200600Z_G23_NN.bufr
unix> ropp_io/tools/bufr2ropp $file -o $(echo $file |sed -es/'.bufr'/'.nc'/)
unix> ncks -H -vpcd $(echo $file |sed -es/'.bufr'/'.nc'/)

dim_unlim[0] pcd[0]=128 

decbufr on the original file reveals

 QUALITY FLAGS FOR RADIO OCCULTATION DATA              Flag 033039 
 .......1........

which is 256.

Part of the problem is line ~500 of ropp_io/bufr/bufr2ropp_mod.f90

      IF ( BTEST(PCD, in) ) ROdata%PCD = IBSET(ROdata%PCD, 15-in)

which should read

      IF ( BTEST(PCD, in) ) ROdata%PCD = IBSET(ROdata%PCD, in)

This correctly gives ROdata%PCD = 256 for GRAS_1B_M02_20140101000329Z_20140101000436Z_R_O_20140709200600Z_G23_NN.bufr.

But even after correcting this, there remain problems with the other two files: GRAS_1B_M02_20140101001207Z_20140101001354Z_R_O_20140709200652Z_G14_NN.bufr outputs ROdata%PCD = 8449 (should be 8448), while

GRAS_1B_M02_20140101174452Z_20140101174657Z_R_O_20140710002204Z_G22_NN.bufr outputs 65535 (it should be 43512).

[Ian Culverwell]

GRAS_1B_M02_20140101000329Z_20140101000436Z_R_O_20140709200600Z_G23_NN.nc

[Ian Culverwell]

GRAS_1B_M02_20140101174452Z_20140101174657Z_R_O_20140710002204Z_G22_NN.nc

[Ian Culverwell]

GRAS_1B_M02_20140101001207Z_20140101001354Z_R_O_20140709200652Z_G14_NN.nc

[Ian Culverwell]

GRAS_1B_M02_20140101000329Z_20140101000436Z_R_O_20140709200600Z_G23_NN.bufr.bufrout

[Ian Culverwell]

GRAS_1B_M02_20140101174452Z_20140101174657Z_R_O_20140710002204Z_G22_NN.bufr.bufrout

[Ian Culverwell]

GRAS_1B_M02_20140101001207Z_20140101001354Z_R_O_20140709200652Z_G14_NN.bufr.bufrout

[Ian Culverwell]

Dave's convinced this is OK:

All,

Remember that the order of bits in BUFR is the opposite 
to that conventionally in Fortran (and other computer 
languages). In the latter, bits are 'least significant 
bit on the right'; thus 1 (as 1 byte) is 0000001 In the 
former, bits are transmitted left-to right, so 1 (as 1 
octet) is 1000000.

Hence the '15-i' to reverse the order in the IBSET 
function in ropp2bufr. There should be an equivalent 
un-reverse in buf2ropp. But note that decbufr does NOT 
perform such an un-reverse - you have to reads the bits 
'backwards' (L-to-R) or 2's-complement the 'decimal' 
number equivalent.

If the flag (pcd) values going into ropp2bufr do not 
come out intact from bufr2ropp, then there is indeed a 
problem, But this would surely have been detected in 
even the IO build test. 

Dave

And the attached test.sh shows that bufr2ropp | ropp2bufr starts and ends with the same BUFR PCD codes, namely

 QUALITY FLAGS FOR RADIO OCCULTATION DATA              Flag 033039 
 .......1........

Reading L-to-R, as Dave says is necessary when reading decbufr output, this is 128, not 256, which you get by reading R-to-L.

Similarly, ropp2bufr | bufr2ropp starts and ends with the same ROPP netCDF PCD code, namely

dim_unlim[0] pcd[0]=128

So it all looks OK.

[Ian Culverwell]

test.sh

[Ian Culverwell]

Closing ticket.

[Ian Culverwell]

Reopening so that we can close it with the more appropriate status of 'invalid'.