NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Paul, The default packing file for dcmetr is metar.pack, which will be found as long as your $GEMTBL environmental variable is set- either in the LDM environment, or by using the -e GEMTBL=...... command line parameter on the dcmetr invocation as is shown in the examples of the pqact entries I have on the GEMPAK web page. Steve Chiswell Unidata User Support >From: Paul Ruscher <address@hidden> >Organization: UCAR/Unidata >Keywords: 200204042211.g34MBja26920 >Excellent and thanks! We must have a problem with our packing files here >and I'll ask our staff to include them in the list of decoded variables >and see if that makes a difference. I completely missed the upper air >stuff, and thanks for pointing that out, too. Bye for now. Paul > >PS - should we be using a particular .pack file or parameter file to look >for these omissions in the 24 hour data? > > >On Thu, 4 Apr 2002, Unidata Support wrote: > >> >> Paul, >> >> >PS - I tried TDXC and TDXF, for example, and find them all to be missing; >> >there are some references to them in PR_TMCF modules but they don't appear >> >to be working properly. >> >> I do have Daily Max/Min decoding in TDXC/TDNC being decoded. The 6 hourly >> values are WMO-region specific as to their reporting: >> >> GEMPAK-SFLIST>r >> PARM = TDXC;TDNC;T6XC;T6NC >> >> STN YYMMDD/HHMM TDXC TDNC T6XC T6NC >> TLH 020404/0000 -9999.00 -9999.00 28.90 21.10 >> TLH 020404/0100 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/0200 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/0300 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/0400 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/0500 28.90 17.80 -9999.00 -9999.00 >> TLH 020404/0600 -9999.00 -9999.00 21.70 19.40 >> TLH 020404/0700 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/0800 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/0900 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/1000 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/1100 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/1200 -9999.00 -9999.00 20.60 15.60 >> TLH 020404/1300 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/1400 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/1500 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/1600 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/1700 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/1800 -9999.00 -9999.00 24.40 15.60 >> TLH 020404/1900 -9999.00 -9999.00 -9999.00 -9999.00 >> TLH 020404/2000 -9999.00 -9999.00 -9999.00 -9999.00 >> >> Also displayable with TDXF, TDNF. >> If there are specific instances of T6XC and T6NC not being decoded >> in a report where they exist at a synoptic time, I can look at the >> report. >> >> The WMO manual on code actually differentiates between a daily >> max/min and a 24 max/min. The dcmetr decoder does follow the WMO standard. >> In 5.4, the dchrly decoder was retrofitted with the NWS/OSO metar decoding >> API (eg not from the NCEP GEMPAK developers) and therefore, the difference >> in naming conventions. >> >> #1/#2) Yes, there is still a backward compatibility to SAO. sfl604 was never > designed >> to be portable past that archine format. The dcmetr decoder is decoding "FEW > ", >> and storing it as a numerical representation. The SFLIST output is then >> translating this to -SCT since it doesn't know what the original input forma > t was. >> Updating these types of airways to metar conversions should be possible just >> as APX-A shows the WNUM conversion for METAR, eg -RA = 13. At present, WTHR >> for 13 outputs R-, but a metar specific outpur routine in GEMLIB following >> the table on A-20 would be appropriate. >> >> #3) see above >> >> #4) I show dcmetr decoding P24I for TLH as .02: >> >> GEMPAK-SFLIST>l >> SFFILE = metar >> AREA = @tlh >> DATTIM = 1200 >> SFPARM = p24i;text >> OUTPUT = t >> IDNTYP = stid >> GEMPAK-SFLIST>r >> PARM = P24I >> >> STN YYMMDD/HHMM P24I >> TLH 020404/1200 0.02 >> >> >> KTLH 041153Z 35005KT 6SM BR FEW055 BKN150 BKN250 16/13 A3014 RMK AO2 SLP207 > 70002 T01560133 10206 20156 53024 >> >> >> #5) dcuair decoding of Max Winds and Trop groups: >> >> >From the 5.6.C release notes: >> >> Several improvements have been made to the decoding and storing of >> upper-air data. >> >> The max winds and tropopause parts, TRPA, TRPC, MXWA, MXWC, are >> now decoded and stored. In addition, the significant winds below >> and above 100mb, PPAA and PPCC, respectively, are now stored as >> separate parts. >> >> Currently, only the program SNLIST can list the tropopause and >> max wind data. NMAP and the other display programs will be modified >> in the future to handle these data types. >> >> The raw text, (undecoded data) is now stored. It can be listed >> in the program SNLIST by setting SNPARM to TEXT. >> >> In SNLIST, set MRGDAT=no and SNPARM=text. The Trop and Max wind groups >> will be shown. As the statement above states, handling these >> with the display programs will be addressed in the future. >> >> I try to encapsulate the features of the release at: >> http://www.unidata.ucar.edu/packages/gempak/GEMPAK5.6/whats_new.html >> >> The $NAWIPS/versions files arethe logs of changes from NCEP. >> >> >> >From: Paul Ruscher <address@hidden> >> >Organization: UCAR/Unidata >> >Keywords: 200204041825.g34IPLa09523 >> >> >Hi, we only recently installed gempak 5.6 and in redoing the necessary >> >scripts, I have found some things no longer supported, at least in our >> >local implementation. I want to get some ideas from you regarding what is >> >supported in the new version first before I ask my local folks to modify >> >packing tables, since I am not even sure if the variables are supported >> >any longer. >> > >> >First question: >> > >> > It appears that T24X and T24N are not available; they appear to >> >have been left out of all "pack" files, at least in our apparent standard >> >install of the latest version of gempak 5.6. >> > >> >Other comments/questions: >> > >> >Gempak is still a useful program for display and listing of data; however >> >the surface decoding programs are still decoding as if the old aviation >> >code is still being used. This comment might be better suited for the >> >user's committee...in any case, here are my observations: >> > >> >1) Clouds are misclassified, with the new (as of 1995) category of FEW >> >(1/8 and 2/8) not being included within the gempak surface decode >> >infrastructure or in output in SFLIST, SFL604, etc. >> > >> >2) Weather types still refer to the old AVIATION abbreviations, rather >> >than the METAR ones in use for the past 6+ years. For example, rain is >> >now RA, not R; all weather abbreviations are now two letters. >> > >> >3) 6-hourly max and min temps are reported for every station every 6 >> >hours, yet, T06X and T06N are not always reportable at these times. >> > >> >4) 24 hour precipitation (P24I) is routinely mis-reported as missing at >> >some (but not all) stations. I can't find a pattern for this that makes >> >sense, but in examining observations for Tallahassee for 12 Z today, our >> >surface file reports the data as missing, but a seemingly valid raw report >> >showing 0.02" is available. >> > >> >5) Remarks could be stored possibly to preserve raw information. >> > >> >Items (1) and (2) on this list, in particular, perpetuate an old style of >> >reporting and makes gempak less attractive to use as a meteorological >> >application; this of course feeds into GARP and other applications that >> >rely on gempak surface files. >> > >> >I continue to have concerns about upper air decoding of files, as well, >> >given that the raw tropopause and maximum wind level data available in >> >rawinsonde reports is not decoded by gempak; this is an issue I brought up >> >years ago to support, but received not much help on. Perhaps now is the >> >time to bring the missing decoded data issue up again. Namely, the >> >following missing information from gempak upper air files: >> > >> > 1) TROP as a "level" has pressure, temp, and wind for each stn >> > 2) MAXW as a "level" has pressure, wind, and wind shear (above >> > and below) for the maximum wind level in a sounding >> > 3) There is also stability index information, and flight failure >> > or other miscellaneous information available that is not >> > decoded and stored, but could be >> > >> >I'm sure that there are probably other issues and I'm sorry I did not get >> >a chance to think about these issues before the most recent User's >> >Committee meeting, or I would have brought them up sooner. In the >> >meantime, can I get a catch-up from support on what is and is not possible >> >within gempak 5.4? Thanks! >> > >> >I've included a "local midnight" observation that includes a sample 24 hr >> >max/min temperature, which was a decodable element in gempak 5.4; the "4" >> >group at the end has the relevant data, 28.9 for the max; 17.8 for the >> >min. >> > >> >huey.ruscher> obs tlh 5z >> >KTLH 040453Z 00000KT 9SM OVC010 21/20 A3008 RMK AO2 SLP183 T02060200 >> >402890178= >> > >> >Thanks in advance for helping out...Paul >> > >> >> **************************************************************************** >> Unidata User Support UCAR Unidata Program >> (303)497-8644 P.O. Box 3000 >> address@hidden Boulder, CO 80307 >> ---------------------------------------------------------------------------- >> Unidata WWW Service http://www.unidata.ucar.edu/ >> **************************************************************************** >> >