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

20020109: dcshef NWS RTP TAIRZX

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: 20020109: dcshef NWS RTP TAIRZX
  • Date: Wed, 09 Jan 2002 16:55:45 -0700
Daryl,

The reading of 4 character parameter names from the
packing file will extend all the way to the gemlib dpfile.f routine
from dcfcyl.f. So, trying to extend the variables to > 4 characters
would not be an viable task. Better off leaving the packing file
limited to 4 characters or less.

A more likely scenario would be to add logic in the conversion from
the repparms() array that allows 7 characaters to the
dparms() 4 characater array so that parameters like
TAIRZX and TAIRZN could be mapped to names like TAZX and TAZN
(or TX, TN).

Steve Chiswell
Unidata User SUpport



>From: Daryl Herzmann <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200201092036.g09KaLN08934

>Hi!
>       I am probably way off on this, but it would appear that in 
>dcshcd.f   The parsed parameters (TAIRZX,TAIRZN) are truncated to 4 
>characters which makes them both (TAIR) .  The known params (2 char) are 
>augmented to 4 char for comparison so TA becomes (TAIR).  The comparison 
>is made and (TAIRZX,TAIRZN) become TA which is iparms == 25
>
>       I am not sure how to fix this problem, if indeed I have 
>found the problem.  I am very new to SHEF, so I have been taking a crash 
>course this afternoon.
>
>       Hope this helps...
>
>Daryl
>
>On Wed, 9 Jan 2002, Unidata Support wrote:
>
>>
>>Daryl,
>>
>>The parameter string appears to allow for 7 characters in the
>>parameter names. I can look into how the time ZX and ZN are
>>being processed after the AMS. But....if you want to look into the 
>>group b decoding and time group, that would be the place to start.
>>
>>Steve Chiswell
>>Unidata User Support
>>
>>
>>
>>
>>>From: Daryl Herzmann <address@hidden>
>>>Organization: UCAR/Unidata
>>>Keywords: 200201091658.g09GwIN25552
>>
>>>Hi!
>>>     I am using dcshef to create gempak surface files from the RTP 
>>>reports issued by the NWS.  An example report is
>>>
>>>ASUS63 KDVN 091414
>>>RTPMLI
>>>
>>>     Anyway, the shef encoding line for the COOP section is
>>>
>>>.BR MLI 0109 C DH07/TAIRZX/TAIRZN/PPDRZZ/SFDRZZ/SDIRZZ
>>>
>>>     and an example station is
>>>
>>>ALEI2: ALEDO              :  44 /  23 /     M /    M /  
>>>
>>>     the subsequent gempak file has
>>>GEMPAK-SFLIST>r
>>> PARM = TX  ;TN  ;TA                                                        
>   
>>>    
>>>
>>>    STN    YYMMDD/HHMM      TX       TN       TA  
>>>  ALEI2    020109/1300  -9999.00 -9999.00    23.00
>>>
>>>     So I am guessing that dcshef took the first value for TAIRZX and 
>>>then overwrote it with the TAIRZN value???
>>>
>>>     RTP reports that use 2 letter shef ids are okay.  An example is
>>>
>>>ASUS63 KARX 091520
>>>RTPLSE
>>>
>>>.BR ARX 0109 C DH07/TX/TN/PP/SF/SD
>>>
>>>OSAI4: OSAGE IA COOP            :  55  / 24  / 0.00/ 0.0 /   0
>>>
>>> GEMPAK-SFLIST>r
>>> PARM = TX  ;TN  ;TA                                                        
>   
>>>    
>>>
>>>    STN    YYMMDD/HHMM      TX       TN       TA  
>>>  OSAI4    020109/1300     55.00    24.00 -9999.00
>>>
>>>
>>>     Suggestions?  Would the fix be as simple as increasing parm 
>>>size to 6?? If so, I would be willing to try and get it to work.  Thanks!
>>>
>>>Daryl
>>>     
>