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: William C Klein <address@hidden> >Organization: Valparaiso >Keywords: 200207191908.g6JJ8H908347 data feeds Bill, >aeolus is the machine that the data should be going to. weather.valpo.edu >is NOT the current server. i'm not quite sure what it's capacity is now. OK, I thought I remembered that LDM ingest and XCD decoding had been setup on aeolus at one time. Someone _is_ running the LDM on weather.valpo.edu, however. It might be interesting to see if the LDM setup on weather coincides with the your missing data. As I write this note, I see that the LDM is also running on aeolus. If both of these machines are trying to write decoded data to the same filesystem/directory/files, you will have significant problems. Also, by running two LDMs, you are most likely using twice the network bandwidth that you need. If I were you, I would review the setup on weather and merge the request and allow lines from its ~ldm/etc/ldmd.conf file into that on aeolus. In particular, I would pay attention to the upstream feed sites that are feeding weather. Are they the same on weather as on aeolus? What machines a site will allow to request a feed from is controlled by the feed site, and they typically will allow only one machine per site. After making the merge, you should stop the LDM on weather. While looking through the LDM setup on weather, make sure to check to see if it had been setup to start the LDM automatically on reboot; if it has you need to remove that capability. Once the LDM is stopped on weather (and will not restart), you should be able to safely start the LDM on aeolus and get everything working there again. Tom