No Designator for Certain Forecast Times (fwd)

• To: bit-bucket <bit-bucket@xxxxxxxxxxxxxxxx>
• Subject: No Designator for Certain Forecast Times (fwd)
• From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
• Date: Wed, 20 Jul 2005 13:09:24 -0600 (MDT)

==============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx                   WWW: http://www.unidata.ucar.edu/
==============================================================================

---------- Forwarded message ----------
Date: Thu, 30 Jun 2005 23:34:45 -0500
From: Jordan Gerth <wiscwx@xxxxxxxxx>
To: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
     decoders <support-decoders@xxxxxxxxxxxxxxxx>
Subject: No Designator for Certain Forecast Times

Hello Mr. Kambic,

T+126, T+138, T+150, T+162, and T+174 hours (where T is the forecast 
initialization 
time) all use the letter Z in place of their forecast hour designator in the 
header's fourth octet. Looking at Appendix A of WMO Bulletin Headers, I do not 
see any other way to break these up by their forecast hour. As a result, they 
are all being saved/amended to the same file in the same folder, which is 
problematic 
for their conversion into AWIPS netCDF format. The converter I have only reads 
the 
first entry (T+126) and then quits, believing the end of the forecast hour is 
the end 
of the file.

Limiting it to Z is an insufficient matter of accomplishing this problem, not 
matter 
how many files I make (they are all Z, so each entry catches every one). The 
only 
fix would seem to be looking outside of the heading and focusing on the GRIB 
PDS. 
How does "> ldmadmin watch" get the forecast time (F###)?

Ref. Table A.3 - http://www.nco.ncep.noaa.gov/pmb/docs/on388/appendixa.html

Meteorologically,

Jordan Gerth