20040331: Unidata LDM feeds for 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

Mai,

>Thank you very much as always for your helps.

No worries.

>Below is what i've done so far.
>
>1) I've set the clock to timeserver.unidata.ucar.edu. 
>
>0,15,30,45 * * * * /usr/sbin/ntpdate timeserver > /dev/null
>
>I've put your suggested line in file 'crontab'.
>Eventhough there is a doubt. Your numbers are
>separated by commas whereas the other entries in the
>file were separated by spaces. So i'm not very sure
>that it will  synchronize properly. But the time is
>changed now.

The meaning of the fields in the crontab entry are (taken from the man
page for crontab from our Solaris SPARC system):

 crontab Entry Format
     A crontab file consists of lines of six  fields  each.   The
     fields  are separated by spaces or tabs.  The first five are
     integer patterns that specify the following:

        minute (0-59),
        hour (0-23),
        day of the month (1-31),
        month of the year (1-12),
        day of the week (0-6 with 0=Sunday).

     Each of these patterns may be either an  asterisk   (meaning
     all legal values) or a list of elements separated by commas.

     An element is either a number or two numbers separated by  a
     minus  sign  (meaning  an  inclusive  range).  Note that the
     specification of days may be made by two fields (day of  the
     month  and  day of the week).

The comma separted numbers in the entry I sent you are the minutes of
the hour when the crontab entry is to run.  This entry says to run
ntpdate every 15 minutes to set the clock.

We have found that the clocks on PC machines (running Linux, FreeBSD,
etc.) drift badly.  It may be sufficient to set the clock once per
hour, but it is better to do it four times per hour.

>2) I've checked with the nslookup and saw the problem.
>I've forwarded it to the IT administator in my office
>and will get the response soon.

OK, thanks.

>3)About HRM grib. Yes, we indeed did changes to the
>variables with ID belows 127. We'll think to fix it
>some how. 

This will be an important thing to do if you want to use a standard
distribution of GEMPAK/NAWIPS.

>  HRM is the German model that we adopted and run it
>operationally in our office. The code for setting the
>center number (78) is written somewhere and we can be
>able to change it.

This explains why the Model Center is set to Offenbach!

>However, we're not sure yet if
>Vietnam has a code site provided by WMO.

We couldn't find one.

>I wonder if
>that code (78) has any significance in GRIB decoding
>procedures.

If you make local modifications to the HRM model, you will want to
change the Model Center ID number from 78 to something like 255.  Then,
the GEMPAK table that lists Model Center IDs can be updated to reflect
that 255 is Hanoi.  What this enables is an automatic association with
the parameter table for parameter numbers greater than 127.  In your
case, this would be a reworked, and probably renamed version of your
hrmgrib.tbl.

If you do NOT make local modifications to the HRM model, you should bet
the grib parameter table defined by the folks that created the model
and use it.  In this case, Model Center ID 78 will be associated with a
particular mnemonic.  If the parameter table is named to correspond to
this mnemonic, then it will be used automatically by the grib decoding
routines in GEMPAK.

>Thank you again.

I will see if we can start doing the installation today.  No promises,
but I will try.

Cheers,

Tom
--
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.