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

20040319: 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

Hi Mai,

We got a chance to logon to your machine, met_research3.nchmf.gov.vn,
to look at a few things.   Here are some observations:

1) the system clock is not set correctly.  As I write this, the
   machine thinks that it is Tue Mar 30 06:51:48 UTC 2004.  It should
   be:  Mon Mar 29 20:49:44 GMT 2004.  The LDM will not work correctly
   unless the clocks on the downstream (your machine) and upstream (our
   machine for right now) machines are synchronized.  It is likely that
   there is a timeserver at your site/in the national weather service
   of Vietnam that you can use to set your clock.  There are two ways
   of setting the clock:

   - run the ntp daemon, ntpd (located in /usr/sbin)

   - run the routine ntpdate (also located in /usr/sbin)

   ntpdate is easier to setup than ntpd.  All you need to do is
   identify a time server that is open to your machine, and
   add an entry to 'root's cron that looks like:

#
# Set the system clock
#
0,15,30,45 * * * * /usr/sbin/ntpdate timeserver > /dev/null

   It is up to you to replace 'timeserver' in the entry with
   the fully qualified hostname of the time server that is
   willing to have you asking for time.  To get you started,
   you can use the machine timeserver.unidata.ucar.edu.
   Your cron entry would then look like:

#
# Set the system clock
#
0,15,30,45 * * * * /usr/sbin/ntpdate timeserver.unidata.ucar.edu > /dev/null

   After your clock gets set correctly, the LDM will begin sending
   data.

2) installing GEMPAK:

>The second point about installing Unidata's GEMPAK.
>I'd love to install it with your guidance. (You've
>been a very good guide so far!). It'll help me to
>become more confident with the system.

   We have a binary GEMPAK distribution for the Fedora Core 1
   version of Linux.  Fedora Core 1 is the free follow-on to
   RedHat 9.  We will download the GEMPAK binary and lead
   you through its installation and setup.

3) your GRIB model data:

>About decoding our GRIB model data. Our model (HRM)
>uses a somewhat modified gribtable. I've created its
>grid table (hrmgrib.tbl) and used nagrib to decode it.
>The output seems okay. But I can't display the output
>file in NMAPS. So the error could be either because of
>the decoding or incorrect configuration of our NAWIPS.
>
>I have put the grib table (hrmgrib.tbl), a sample data
>files of hrm (hifff00000000p) and  the output from
>nagrib (hrm_2003111600f000) in the directory VNdata in
>ldm account. Please have a look if it's been corrected
>converted. (note that the grib table is just a subset
>of our variables, but those are all variables that
>i've output from the model for this instance). 
>
>If the converting is fine, it means that i've
>incorrectly configure our NAWIPS. And it will be
>double benefits of installing the official version of
>Unidata's GEMPAK.

We grabbed all of the files in ~ldm/VNdata so we could look
at your GRIB table, and the output from your model.  We
found that you/the modelers are doing some things in a
non-standard manner.  One should try to use parameters
defined in standard GRIB tables for parameter numbers
0 - 127.  If one wants to have locally defined parameters,
they should be assigned GRIB numbers between 128 and 255.

- your GRIB table, hrmgrib.tbl, is redefining parameter
  numbers in the 0-127 range.  This makes adding your
  GRIB table to GEMPAK not possible

- the modelling center number in your GRIB messages is 78.
  78 is the number for the Offenbach center in Germany.
  You should try to find out if WMO has assigned a center
  number for Hanoi and use it in your GRIB messages.

- GEMPAK has conventions for parameter names that, when
  followed, make conversions between different coordinate
  systems transparent.  For instance, instead of using
  the name T for temperature, it would be better to use
  the GEMPAK standard TEMPK (Temperature in Kelvin).

There are more issues, but I wanted to get this note to you so
you could address the time problem as soon as possible.

>About the DNS again, we have some delay due to the
>paperwork procedure. But it should be ready early next
>week (I hope)

>From address@hidden  Fri Mar 26 22:53:55 2004

>How is your LDM data stream. Is the IP <=> DNS lookup
>working properly? Can I do anything about it?

The DNS partially works.  One can find the machine's IP from
its fully qualified hostname, but one can not find the fully
qualified hostname from the machine's IP:

% nslookup met_research3.nchmf.gov.vn
Server:  laraine.unidata.ucar.edu
Address:  128.117.140.62

Non-authoritative answer:
Name:    met_research3.nchmf.gov.vn
Address:  203.162.14.98

% nslookup 203.162.14.98
Server:  laraine.unidata.ucar.edu
Address:  128.117.140.62

*** laraine.unidata.ucar.edu can't find 203.162.14.98:Non-existent host/domain

>When can I start to install your McIDAS version of
>NAWIPS?

I am out of the office tomorrow, so this will have to wait until
Wednesday.

>And have you look at the problem of the GRIB and
>surface file conversion for me?

See above.

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.