G. Walters 2001Oct31 NCEP SOUNDING TYPE IRREGULARITY In the course of preparing our "super" inventories, my software which distinguishes between raobs and pibals was confused by the data in a period during 1987. From 6Z on March 25 through 6Z on June 23, about 200 pibals at each 6-hourly time were being classified as raobs due to an unusual pressure value that appeared in the significant level data (ON29 Category 02). These soundings, due to the appearance of a temperature at the only pressure level in the sounding, were thus being misidentified. Being the first and only level in the Category 02 section of the report, the documentation indicates that this would be the surface level, but in these particular soundings, they have a surface pressure greater than 9000mb. We decided to ignore the temperatures on significant levels with bad pressures. Another intriguing fact about these particular soundings: the entire world was involved, except North and South America, and China! We suspect this situation may be due to an irregularity in reporting practises or in NCEP's processing - where perhaps surface reports somehow got mixed into the upper air reports, and then perhaps NCEP altered the pressure (multiplied by 10?) as a signal to ignore the level. Ignoring the temperatures on significant levels with bad pressures does not affect the total number of soundings. It merely shifts misclassified soundings from raobs to pibals, thereby maintaining consistent counts. As programmed, the wind at this level will still be enumerated in the pibal records in the "super" inventories. -------------------------------------------------------------------------------- G. Walters D. Joseph 2000May02 rev.2001Oct31 BAD CATEGORY/COUNTER GROUP A user recently reported numerous decode errors appearing in the output from our readupa.f software while processing the 1998Jun-1999Oct files. Investigation found that NCEP had flooded a field in the category/counter group section of the ID for certain upper air significant level reports. Specifically, character locations 48 - 50, which are supposed to contain the total number of characters in the current category. For a few obs, about 3 per day on average, coming from the tropical eastern Pacific, there are so many category 2 and/or category 4 levels, that the total number of characters exceeds the maximum which this field can show. Our access software was sensitive to this, hitting the field of asterisks and printing a decode error. However, the software actually calculates the correct value from the number of levels specified in characters 46 - 47 by multiplying by the known fixed length of the appropriate category. Nevertheless, we needed to increase the size of the arrays into which the mandatory levels and significant levels are unpacked and merged. Users should therefore obtain the latest copy of readupa2.f in order to properly handle this condition.