This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>From: Matt Rosier <address@hidden> >Organization: UNCA >Keywords: 200307301533.h6UFXPLd024978 LDM McIDAS upgrade ETA GFS GEMPAK Hi Matt, >Do you know how we can correct the problem of not receiving (or not decoding >perhaps) Eta data past 60 hrs or so and AVN data past 84 hrs? I just looked at the McIDAS-XCD decoded GFS data on storm2, and it extends to 120 hours, the McIDAS-XCD decoded ETA extends to 72 hours, and the volume of HDS data you are ingesting indicates that nothing seems to be missing. Given all of this, I must assume that the problem you are seeing is in GEMPAK? If yes, I will ask Chiz to check into this. >Thanks, I do see a small 'time' problem on storm2. You can see from the latency plot for any feed storm2 is ingesting that the clock is drifting. For example, take a look at: http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_nc?IDS|DDPLUS+storm2.atms.unca.edu I was going to add running of xntpdate from 'root's crontab file, but xntpd is already running: % ps -aux | grep ntp ntp 750 0.0 0.2 2400 2392 ? SL Aug27 0:01 ntpd -U ntp -g An incorrect clock is not the cause of you not having the decoded HDS data you want, but it will become a problem as the magnitude of the time offset on storm2 worsens. Given this, I decided to investigate. Quickly looking through the ntpd configuration file, /etc/ntp.conf, I see what may be an error: restrict 152.18.69.33 255.255.255.255 server 152.18.69.33 # candler.cs.unca.edu restrict 152.18.68.2 mask 255.255.255.255 server 152.18.68.2 # craggy.unca.edu Notice how the first 'restrict' line has an IP address followed immediately by a netmask, but the second contains the word 'mask' between the two. The correct syntax is to include 'mask' between the IP and the netmask. This may be the problem of the clock not being set. I corrected this entry. I got together with my system administrator and we decided to run ntpdate on storm2 instead of ntpd. To get this working, we did the following (all done as 'root'): 1) stop ntpd: /etc/init.d/ntpd stop 2) prevent ntpd from being run at boot: chkconfig ntpd off 5 3) add an entry to 'root's cron that runs ntpdate once per hour: # # Set system clock 0 * * * * /usr/sbin/ntpdate 152.18.69.33 > /dev/null 4) verified that the clock is now correct on storm2 Finally, since I promised to report back all of the changes we made on storm2, I offer the following which is more-or-less complete: - as we noted in a previous email, we modified the 'exec "pqact..."' entry in ~ldm/etc/ldmd.conf so that the -d flag is now '-d /home/ldm'. Previously, it was '-d /home/ldm/data' which was non-standard - we split the pqact.conf files up into a GEMPAK one, a general one that contains the needed actions for McIDAS, and three ones for DIFAX map printing. We altered the cron job that rotated DIFAX printing pqact files, and changed stopping and restarting the LDM into sending a HUP signal to pqact. This is much more efficient. - I moved where the decoded McIDAS data was being stored from /data/mcidas to /data/ldm/mcidas. In order to make all of the McIDAS XCD and ADDE serving setup keep working, I had to change the set of file REDIRECTions that were being used (so that McIDAS will find the data files in the new location), and I had to change the McIDAS string XCDDATA to point to the new directory: <as 'mcidas'> cd ~mcidas/workdata te.k XCDDATA \"/data/ldm/mcidas Since there was movement of where data is stored, I also updated the REDIRECT local template copy ~mcidas/data/LOCAL.NAM to reflect the new directory location. - I installed McIDAS-X v2003 on three UNCA machines: storm2, typhoon, and lab1. I uninstalled and then reinstalled the ADDE remote server configuration as 'root': cd /home/mcidas sh ./mcinet2002.sh uninstall mcadde sh ./mcinet2003.sh install mcadde This was done on all three machines. - I updated the LOCAL.NAM file on typhoon and lab1 with the same settings as are on storm2. I then made the REDIRECTions active by restoring them as 'mcidas': cd ~mcidas/workdata redirect.k REST LOCAL.NAM This was done on all three machines. - I logged onto typhoon and lab1 as the user 'atms' and setup the McIDAS environment so that it would use the datasets on storm2 where available and on remote machines for datasets that storm2 does not have. Things appear to be working correctly. My observation is that McIDAS-XCD data decoding is working correctly and that all of the data that is being created can be served by the ADDE remote server on all three machines: storm2, typhoon, and lab1. The seving on typhoon and lab1 is possible since the data directory where XCD is writing its output on storm2 is mounted on both typhoon and lab1. As I finish this, I am waiting for Chiz to get into work (he is a new dad) so I can ask him about the ETA and GFS decoding problem you reported. Cheers, Tom