Wring COSMIC IDs

[Dave Offiler]

Santi reported a problem converting some COSMIC files to BUFR, for which the satellite ID goes AWOL. Josep traced this to:

Hi all,

Ok, I got it.

In         ropp_io/bufr/convertcodes.f90

The list of names LEOlist
says that the shortnames of COSMIC are   CO01 to CO06      (note the letter O, not the number 0, so two letters+two digits).
UCAR, however, uses C001 to C006 (one letter+three digits).

This list ends being forwarded to the namelist
$BUFR_TABLES/roppbufrcodes.nl

So this namelist file should also be edited or regenerated.

If LEOlist is corrected as above, then the LEO is identified, and its standard number is written to the BUFR file.


Josep

The 2-letter/2-digit IDs have been in use from the beginning, so I'm not sure why this had not been found long ago. It wouldn't have been caught by the standard make test because the test and pre-generated reference BUFR files (and hence the decoded file) would have both had 'missing data' for this parameter, so would pass the automated diff test.

The problem is easily confirmed by running ucar2ropp on the test file ropp_io/data/ucar_test.nc. The satellite ID code is extracted from the fileStamp parameter. On inspection with ncdump the code is C006; this value is copied into the ROPP netCDF file as parameter leo_id. Then when running ropp2bufr this code will not be matched, and an unknown BUFR code substituted. This can be confirmed using the decbufr tool. Editing the namelist file to the correct code allows the encoder to match C006 and to map this to BUFR code value 745 which decbufr maps back to COSMIC-6.

The solution simply is to change the satellite (text) ID in both the code (optional) and namelist to the 1-letter/3-digit form used by UCAR/CDAAC. Santi has modified his local namelist file and this has cured his problem. Both files need to be corrected for the release version of ROPP-8.

[Dave Offiler]

Both namelist and code updated to change the 2nd character from letter-O to digit-0 for all 6 COSMIC entries in my do_exitcodes branch.

Tested by:

1. Generate ROPP netCDF from sample data/ucar_test.nc using (pre-built) ucar2bufr; use ncdump to confirm C-oh-zero-6 copied into leo_id in ROPP file.

2. Encode ROPP netCDF file to BUFR with pre-built ropp2bufr; use decbufr -d on resulting BUFR file to confirm 'missing data' flag displayed for satellite ID.

3. Run 'make' to re-build convertcodes.f90 and thence ropp2bufr (and other I/O tools) locally; copy updated roppbufrcodes.nl to $BUFR_LIBRARY.

4. Re-run step 2. This time the BUFR satellite ID displays as 'COSMIC-6'. This validates the new namelist.

5. Temporarily rename the namelist in $BUFR_LIBRARY and re-run step 4. As expected, ropp2bufr issues a warning about not finding the namelist and falls back on the internal tables (in convertscodes()). Again the decode displays 'COSMIC-6'. This validates the new internal tables.

NB: Only tested with default ifort and a single COSMIC-6 file. Visually re-checked the other COSMIC entries are changes consistently, so confident that this change will apply equally to all 6 COSMIC IDs.

[Dave Offiler]

Changes committed as [4277]. Leaving ticket open until reviewed & accepted for ROPP-8.

[Ian Culverwell]

Changes committed at [4281]. They pass the attached test script, generating

 SATELLITE IDENTIFIER                                  Code 001007     COSMIC-6
 SATELLITE INSTRUMENTS                                 Code 002019 CHAMP GPS so

rather than

 SATELLITE IDENTIFIER                                  Code 001007    - - - - -
 SATELLITE INSTRUMENTS                                 Code 002019    - - - - -

in the BUFR file.

(Note that the above text is confused: it's C006 that'in the ucar_test.nc, and which ropp2buf didn't understand.)

[Ian Culverwell]

(Note the need to be careful to use unadulterated roppbufrcodes.nl when building control, as in script above, otherwise the new one will be used in the code, because the one in $BUFR_LIBRARY or $BUFR_TABLE will be used by default, and these are overwritten when you rebuild with the revised namelists. So very old code (in my case, ROPP61 stuff) will use up-to-date namelists unless told not to - with puzzling results.)

[Ian Culverwell]

Closing ticket.