20030304: 20030223: Gempak - IRIX64 - dclsfc problems

>From: =?ISO-8859-1?Q?Christian_Pag=E9?= <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200303042021.h24KLF317077

>Hi Steve,
>
>Is it possible to specify to dclsfc to bin obs in 1 hour blocks?
>

No, that is hardcoded into the routine I mentioned. It is not
a configurable parameter.

Steve Chiswell


>Christian Pagé
>UQAM
>
>On Mardi, mars 4, 2003, at 14:52 America/Montreal, Unidata Support  
>wrote:
>
>>
>> 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,
>>>
>>>
>>>
>>
>> *********************************************************************** 
>> Unidata User Support                                    UCAR Unidata  
>> (303)497-8643                                                  P.O.  
>> address@hidden                                   Boulder, CO  
>> ----------------------------------------------------------------------- 
>> Unidata WWW Service                         
>> *********************************************************************** 
>>
>
>Christian Pagé
>address@hidden
>http://meteocentre.com/    http://meteoalerte.com/
>
>Etudiant au Doctorat en Sciences de l'environnement UQAM
>+1 514 987 3000 ext. 2376
>