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

20021025: Running dcuair



Kwan-yin,

Since upper air data sets in TTAA, TTBB, etc parts do not contain
the latitude/longitude of the station, the dcuair decoder
uses $GEMTBL/stns/snstns.tbl (by default) for locating
the station locations.

If you have older data, where the station locations have moved, 
you can either:

1) create a new station table, and use the -s "stn_table" parameter
with dcuair to use that table instead of the default table.

2) If you have already created the GEMPAK upper air file, you can change
the station location information using the SNSTNS program and a table
of locations for specific stations that have moved in order to
update the data base information for the station in the GEMPAK
upper air file.

Steve Chiswell





>From: "Kwan-yin Kong" <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200210250548.g9P5mVq09495

>To Steve / GEMPAK support:
>
>      Thanks for your hints.  I didn't realize that the 
>'ZCZC' and 'NNNN' need to be added for EACH rawinsonde 
>station.  After I added those in, dcuair appeared to be 
>able to decode most of the stations in the files.
>
>      A question came up to me is: Can GEMPAK decode old 
>stations that have been superceded?  When I try to use 
>oabsnd to do a barnes analysis, do I need to add those 
>superceded station locations into a station table?
>
>Kwan
>City College of New York
>
>
>On Tue, 22 Oct 2002 16:55:14 -0600
>  Unidata Support <address@hidden> wrote:
>>>From: "Kwan-yin Kong" <address@hidden>
>>>Organization: UCAR/Unidata
>>>Keywords: 200210222222.g9MMMHp21301
>>
>>>To Steve / GEMPAK support:
>>>
>>>      Lately, I obtained some rawinsonde data in ASCII 
>>>format and would like to running the decoder "dcuair" to 
>>>convert them to gempak files.  I ran dcuair as suggested 
>>>in the GEMPAK manual with the -c option plus the date and 
>>>outfile < infile.  However, the program stopped almost 
>>>immediately and reported that 'The buffer has overflowed, 
>>>no end of bulletin'.  I still don't understand what this 
>>>message is about, and would appreciate some help.  The 
>>>following is a print-out of the entire error message.
>>>
>>>[10919] 021022/1807 [DC 3]  Starting up.
>>>[10919] 021022/1807 [DC -7]  The buffer has overflowed, 
>>>no 
>>>end of bulletin.
>>>[10919] 021022/1807 [DC 5]  Normal termination.
>>>[10919] 021022/1807 [DC 2]  Number of bulletins read and 
>>>processed: 5
>>>[10919] 021022/1807 [DC 6]  Shutting down.
>>>
>>>Thanks for any inputs on this issue.
>>>
>>>Kwan-yin Kong
>>>City College of New York
>>>
>>
>>
>>Kwan-yin,
>>
>>It sounds like your data is missing the necessary control 
>>characters
>>used in the normal transmission of the upper air data.
>>
>>In the real-time data stream you will find sequences 
>>beginning with
>>^A \r \r \n 
>>and the product ends with 
>>\r \r \n ^C
>>
>>or 
>>
>>ZCZC
>>and ending with
>>NNNN
>>
>>
>>If your archived data has these characaters stripped out, 
>>then you would have to
>>recreate them, such as is described in:
>>http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/gempak/msg035
> 78.html
>>
>>See if your data looks like that described in the 
>>archived message above,
>>and if so, add the ZCZC and NNNN sequences as described.
>>
>>Steve Chiswell
>>**************************************************************************** 
>><
>>Unidata User Support 
>>(303)497-8643 
>>                                                 P.O. Box 
>>address@hidden 
>>---------------------------------------------------------------------------- 
>><
>>Unidata WWW Service 
>>                       http://www.unidata.ucar.edu/ 
>>**************************************************************************** 
>><
>