20040413: Vietnam and GEMPAK GRIB decoding (cont.)

>From: Mai Nguyen <address@hidden>
>Organization: National Center for Hydro-Meteorological Forecasting of Vietnam
>Keywords: 200312020023.hB20N4p2027742 IDD LDM Linux GEMPAK

Hi Mai,

>Thank you and Chiz for working on my problems!

No worries.

>I've tried to reproduce your "technique" but got stuck
>at the 4th step:
>
>> 3) here are examples of report segments we don'
>> understand:
>> 
>> 722030024004AAXX48/8622000022001M048/86 ...
>> 402020028004AAXX4800402000002004K048004 ...
>> 422030010004AAXX4800822000022004K048008 ...
>> 614030056004AAXX4801014000014004K048010 ...
>>  etc.
>
>Yes, that part has been added in our system for some
>purposes.

OK.  They have to be stripped out for the GEMPAK decoder to
work.

>> Also, some of the apparent station IDs are
>> suspect.  Here
>> are a couple of examples:
>> 
>>    48/89
>>    48/93
>
>Those are correct IDs for our "national" stations. I
>have put the station index file in
>/ldm/VNdata/SYNOP/VN_synstns.txt.

It is is not legal to have a '/' character as part of a 
station ID.  The GEMPAK decoder assumes that the '/' is a
missing value.  The decoder is expecting a valid WMO
station ID number, and those are composed of 5 digits.

>I guess I will have
>to add the extra file to some sfstns.tbl for dclsfc to
>look at while decoding. But I couln't find the
>appropriate *.tbl file in $GEMTBL. Do you know which
>table that will be "exactly" read by dclsfc? 

Chiz will have to answer this one.

>> 4) next, add appropriate headers to make the file
>> contents look
>>    like a WMO bulletin:
>> 
>> ^A^M^M
> 999
>> AAXX 22004
>> 
>>  ...                  <- stripped file contents from
>> steps above
>> 
>> ^M^M
>> ^C
>> 
>>    NOTES:  '^A^M^M'  -> CTRL-A CTRL-M CTRL-M (SOH \r
>> \r)
>>            '999'     -> broadcast sequence number
>>            'AAXX 22004' -> AAXX type followed by
>> DDHHn
>>                            DD -> day
>>                            HH -> hour
>>                            n  -> type of unit (see
>> info for FM-12 from WMO)
>>            '^M^M'       -> CTRL-M CTRL-M (\r \r)
>>            '^C'         -> CTRL-C (ETX)
>> 
>
>How do I add CTRL-M , etc. to the text file?. Simply
>adding '^M' doesn't work.

There are many ways that these sequences can be created.
I used 'vi' and typed them in.  For your convenience,
I created two additional files 'begin' and 'end'
and put them in the /tmp directory on met_research3.
'begin' needs to be edited to set the day and time of the
observations; the current AAXX line reads:

AAXX 22004

So, another couple of steps need to be added to the
sequence to do the conversion:

cp ~ldm/VNdata/SYNOP/AAXX00 /tmp
dos2unix AAXX00
cat AAXX00 | sed 's/=  */=\n/g' > AAXX00.1
cat AAXX00.1 | tr -d '\000' > AAXX00.2
cat begin | sed 's/AAXX 22004/AAXX 13004/' > AAXX00.3
cat AAXX00.2 | sed 's/^.*AAXX..................//' >> AAXX00.3
cat end >> AAXX00.3

source ~gempak/NAWIPS/Gemenviron
cat AAXX00.3 | dclsfc -v 4 -d - -c 040322/0000 YYYYMMDD_syn.gem

You need to replace 13004 with the ddhh4 that is appropriate:

dd -> two digit day number
hh -> two digit hour number

Examples:

13004 -> day 13, time 00 UTC
13064 -> day 13, time 06 UTC
14124 -> day 14, time 12 UTC
 etc.

You also need to specify the correct year, month, day, hour, 
and minute in the dclsfc invocation.  The match for 13004 would
be 040413/0000, etc.

AAXX00   -> copy of original file converted from DOS to Unix format
AAXX00.1 -> added line breaks between reports
AAXX00.2 -> strip out bogus (nil) characters
AAXX00.3 -> contains header, stripped out portions of reports that
            do not follow FM-12, and trailer
20040322_syn.gem -> resultant file of decoded obs

>Maybe that's the reason that makes my dclsfc call
>failed! 

Probably yes.

>Thank you as always and wish you a good week!

You too.

Cheers,

Mai
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.