UCAR2ROPP Product Confidence Data (PCD) Flags require update

[frae]

The current reading of ucar data in ropp_io/tools/ucar2ropp.f90 just sets all Product Confidence Data (PCD) flags to 0 if the occultation is flagged good by UCAR, otherwise they are all set to 1. This is incorrect, e.g. setting and rising should be distinguished. This will need to be updated one day and this ticket assures that it does not slip our minds. The PCD does not allow missing data at the moment.

[Dave Offiler]

Since the PCD word only has 16 significant (defined) bits, the value for missing PCD is currently 65535 (all 16 bits set) in the ropp_io_types initialisation. The current ucar2ropp bit setting is consistent in saying 'PCD is missing/invalid', so in that sense is correct.

Of course this only applies to the complete PCD being invalid; individual bits can only be 0 or 1 and so no 'missing bit' can be defined. The ROPP Interface File Format document suggests that if any individual flag is invalid or unknown, it is just set to 0.

If there is info in the UCAR netCDF that is relevant to setting individual bits (like asc/desc), then obviously it should be dug out at some point. Since UCAR are setting bit 8 (open loop) in their BUFR products, other info ought be there too. (Though I don't think UCAR mean 'open loop' in the sense of the GRAS open loop mode).

On a related PCD topic, bit 1 should be set if *any* of bits 4,5,6,7,14 are set. I don't think this is happening. It would be desirable that all the conversion tools set this bit appropriately to make sure. The intent is that although somewhat redundant, bit 1 serves as a summary flag and the user need only test this and if 0 proceed; if 1, then either skip this profile or test other bits to see what the problem was.

[(none)]

Milestone 2.0 deleted

[Huw Lewis]

There is presently no such information (e.g. rising/setting) in the COSMIC files (atmPrf).

It is, however, possible to set the 'rising' and 'openloop' flags in the PCD as part of ropp_pp processing. This is now implemented in ropp_pp_preprocess (see [2115]).

Keep open and move ticket to next milestone as reminder to ask COSMIC for rising/setting information in the Level1b/Level2a atmPrf files provided to users.

[Huw Lewis]

Request for clarification sent to Doug Hunt, UCAR on 29/09/09.

[Huw Lewis]

See [2257].

Doug Hunt replied:

There is an attribute in the atmPrf files to tell rising 
occultations from setting:

'irs' =  1 for setting occultations

       = -1 for rising occultations

Thus, the irs attribute is read from an atmPrf format file and PCD flag PCD_rising set when irs=-1.

Ticket closed as fixed.