NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
>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.