20001229: 20001228: NWX problem

David,

If sflist can't find any TEXT in the file, then that would be a problem 
with NWX too.

The decoder entry below appears correct, and is the same as I am using
here under solaris from the LDM. 

Running sflist with:
 SFFILE   = metar
 AREA     = @den
 DATTIM   = all
 SFPARM   = text
 OUTPUT   = T
 IDNTYP   = STID
 GEMPAK-SFLIST>r
<snip>
KDEN 291553Z 15008KT 10SM FEW160 SCT250 M04/M08 A3030 RMK AO2 SLP294 ACSL DSNT 
SW-W T10441078   
KDEN 291653Z 14009KT 10SM FEW200 SCT250 M02/M08 A3031 RMK AO2 SLP294 CCSL DSNT 
SW-W T10171083   
  
 Parameters requested: SFFILE,AREA,DATTIM,SFPARM,OUTPUT,IDNTYP.
 GEMPAK-SFLIST>


The above works for me on both solaris and osf/1.

You might try taking a raw metar file and sending it through dcmetr 
my hand with -v 4 to see if there are any strange messages, and
verify that the decoded file does not contain TEXT or SPCL
when done that way also.

Steve Chiswell
Unidata User Support



>From: David Ovens <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200012291501.eBTF1Ro18317

>Steve and Harry,
>
>SFPARM=text does NOT display anything, but gives this
> [SFLIST -4]  No valid computable parameters.
>
>Our pqact.conf entry does not contain the -n flag, however. Here it is:
># sfc obs and specials
># Use -m 72 to store data in 20 minute bins, rather than hourly.
># 20 minute bins useful for mesonet and AWOS data
>#
>DDS|IDS        ^S[AP].* .... ([0-3][0-9])([0-2][0-9])
>       PIPE    /home/ldm/NAWIPS-5.6/bin/sol/dcmetr -b 9 -m 72 -s sfmetar_sa.tbl
>       -d data/gempak/logs/dcmetr.log
>       -e GEMTBL=/home/ldm/NAWIPS-5.6/gempak/tables
>       data/gempak/surface/YYYYMMDD_sao.gem
>
>Do you see the problem here?  I don't.
>
>David
> 
>
>Unidata Support wrote:
>> 
>> >From: Harry Edmon <address@hidden>
>> >Organization: UCAR/Unidata
>> >Keywords: 200012282354.eBSNsVo26419
>> 
>> >We have a problem with nwx in 5.6.A (and 5.6).
>> >
>> >  Nwx: 
>> >   Data --> Observed Data --> Surface Hourlies 
>> >   This feature is not working.  When you click on a site you get no data.
>> >
>> >By using truss, it appears that the correct surface file is being opened.
>> >
>> >
>> >--
>> >Dr. Harry Edmon                     E-MAIL: address@hidden
>> >(206) 543-0547                      FAX:    (206) 543-0308
>> >Dept of Atmospheric Sciences
>> >University of Washington, Box 351640, Seattle, WA 98195-1640
>> >
>> 
>> 
>> Harry,
>> 
>> This feature works for me. You have to be storing the raw obs using dcmetr
>> (eg, not using the -n flag)  so that nwx can retrieve these from the
>> decoded file. Are you storing the decoded files as YYYYMMDD_sao.gem?
>> Nwx is pretty picky about file naming, but if you see that the correct files
>> are being opened, and the raw obs (eg SFPARM=TEXT in sflist shows the obs)
>> are in the file, then maybe its the station IDs. The $NWX_TABLES/sfstns.tbl 
>> uses 3 letter IDs as the form for retieving the stations from the surface fi
> le, 
>> so this should agree with the table you are using for the decoded data.
>> 
>> Can you give me details? Is this all OS's?
>> 
>> Steve Chiswell
>> ****************************************************************************
>> 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/     
>> ****************************************************************************
>> 
>
>
>-- 
>
>David Ovens            e-mail: address@hidden
>(206) 685-8108          plan: Real-time MM5 forecasting for Pacific Northwest
>Research Meteorologist
>Dept of Atmospheric Sciences, Box 351640
>University of Washington 
>Seattle, WA  98195
>