20020404: 20020404: question on surface variables for gempak 5.6

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/     
>> ****************************************************************************
>>
>