[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.

  • Subject: 19991020: dchrly not decoding European/Scandinavian Altimeters
  • Date: Thu, 21 Oct 1999 12:39:45 -0600
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 
>
> 
> 
>