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

20030223: Gempak - IRIX64 - dclsfc problems



Christian,

The dclsfc decoder bins the report times into 3 hour blocks,
so your 17Z and 18Z observation will be stored as the same
synoptic observation time.

The routine lsgemp.f opens the GEMPAK file, rounds the observation
time and sets the station position in the file. If the station is
already decoded for that time, it is not overwritten if the 
report is not a correction. Eg:

C
C*          If the data has already been decoded and this is not
C*          a correction, do not decode again.
C

As a result, since your 18Z observation is not a correction,
it is being rejected.

Steve Chiswell
Unidata User Support



>From: "Christian =?ISO-8859-1?Q?Pag=E9?=" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200302231947.h1NJlQg13472

>Institution: UQAM
>Package Version: 5.6.H
>Operating System: IRIX64
>Hardware Information: SGI
>Inquiry: I have some problems with dclsfc with Germany synop data.
>
>I'll take by example data for station WMO ID 10384.
>The min and max temps are sent at 18GMT (I modified slightly dclsfc so that al
> l min and max temps for European region is taken as 12-hr min and max, since 
> if not they were not decoded).
>But data for station 10384 is sent also at 17GMT, but with no min and max temp
> s (group 1 and 2 in group 333 are absent).
>It seems that if I decode manually only 18GMT data, the min and max are decode
> d correctly.
>But running dclsfc with ldm, I don't get these.
>
>Here is the raw data which is relevant:
>SNDL22 EDZW 231700^M^M
>AAXX 23171^M^M
>10384 42968 01203 10055 21070 30273 40335 55003^M^M
>  333 55305=^M^M
>
>SMDL01 EDZW 231800^M^M
>AAXX 23181^M^M
>10384 32970 01302 10042 21073 30274 40336 53001^M^M
>  333 10079 21034 34105 4/998 55300=^M^M
>
>In the logs, I can see:
>[16268189] 030223/1706 [DCLSFC 7] 479 SNDL22  EDZW    231700
>[16268189] 030223/1706 [LS 6] 10384 42968 01203 10055 21070 30273 40335 55003 
> 33
>
>which means that SNDL22 EDZW 231700 is decoded correctly for station 10384.
>
>But, later:
>[16268189] 030223/1805 [DCLSFC 7] 912 SMDL01  EDZW    231800
>[16268189] 030223/1806 [DC 2] read 155/6067 bytes strt 10317 newstrt 10472
>
>which means that no data in the SMDL01 EDZW 231800 is decoded. This data inclu
> de the 10384 report with min and max temps.
>
>Is it a bug? Why when I decode manually these two reports with dclsfc I do get
>  all the correct data for 10384?
>
>Thanks,
>
>
>