NSF Unidata

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

19991020: dchrly not decoding European/Scandinavian Altimeters

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.



Robert,
Dchrly is decoding the altimeter settings in millibars,
however the packing file range flags the data as -9999
because they are out of the valid range.

The cause is that the conversion from millibars to altimeter is
inadvertantly backwards, leading to a bogus value. To fix:

Edit $GEMPAKHOME/src/bridge/metar/parse_metar.c, at ~line 179,
change:
*alti = ((float)Mptr->hectoPasc_altstng) * 1013.25 / 29.921;
to
*alti = (float)Mptr->hectoPasc_altstng * 29.921 / 1013.25;

The recompile the bridge library routine and dchrly program with:

cd $GEMPAKHOME/src/bridge/metar
make clean
make all
make clean

cd $GEMPAKHOME/src/programs/dc/dchrly
make clean
make all
make install
make clean

Steve Chiswell
Unidata User Support





>From: weather <address@hidden>
>Organization: .
>Keywords: 199910201811.MAA01425

>I have been working on a webpage for our upcoming Sweden 
>campaigns and am using GEMPAK to create a surface plot
>for synoptic data.  While doing the same thing today for
>METARS I realized that dchrly is not decoding the altimeters
>which are in millibars.  The McIDAS decoders are working properly:
>
>GEMPAK-SFLIST>l
> SFFILE   = /var/data/ldm/gempak/surface/19991020_sao.gem
> AREA     = @ESSA
> DATTIM   = 16
> SFPARM   = sali
> OUTPUT   = t
> IDNTYP   = stid
> GEMPAK-SFLIST>r
> PARM = SALI                                                                  
>    
>
>    STN  YYMMDD/HHMM      SALI
>   ESSA    991020/1600          
> 
> 
> I can get the raw ob:
> 
> GEMPAK-SFLIST>l
> SFFILE   = /var/data/ldm/gempak/surface/19991020_sao.gem
> AREA     = @ESSA
> DATTIM   = 16
> SFPARM   = text
> OUTPUT   = t
> IDNTYP   = stid
> GEMPAK-SFLIST>r
>ESSA 03003KT 9999 SCT020 BKN045 04/01 Q1028 NOSIG=  
>
>   
> McIDAS:
> /export/home/weather% sfcrpt.k ESSA 2
>ESSA 35002KT 9999 BKN020 02/M00 Q1028 NOSIG=
>ESSA 35001KT 9999 BKN020 BKN045 04/01 Q1028 NOSIG=
>sfcrpt.k: Done
>/export/home/weather% 
>
>/export/home/weather% sfclist.k ESSA 2
> Day Time StCo  Stn   T  Td  Dir Spd Gus AltSet  Vis  Weather  Ceil
>     hhmm        id  [F] [F]     [ kts ]  [mb]   [mi]
>---- ---- ---- ----- --- --- --- --- --- ------ ----- -------- -----
>  20 1700   SN ESSA   39  34 350   1     1028.0  7.00          5/020
>  20 1800   SN ESSA   36  32 350   2     1028.0  7.00          5/020
>Number of reports = 2
>sfclist.k: done
>/export/home/weather% 
>
>
>I could do the METAR map with McIDAS, but for various reasons
>want/need to use GEMPAK.  Any ideas, or am I simply not putting 
>in the right sfparm (although I have tried all of them I think).
>
>Thanks,
>Robert Mullenax 
>
> 
> 
>