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.
Hi Elmer, re: > I have checked the system we get the data from and can see nothing > wrong. Question: - did you run a 'notifyme' on that system and verify that it is getting all (or what looks like it should be all) of the NLDN data contained in NOAAPort > The files are there as an example, nldn_200901604, where as the > files that get written for conversion to MD files are every 5 mins in > the form of NLDN20090141935. OK, so it does sound like the files are being received consistently by the machine you are requesting the data from. > So, I thought that there was a possibility > that something had changed. Nothing has changed as far as we know. We do not, however, get our NLDN lightning data from NOAAPort. The university community gets its NLDN feed from Suny Albany's Department of Atmospheric Science. This IDD feed is restricted to university sites by SUNYA's agreement with the owner of the data. The NLDN data in NOAAPort, on the other hand, is intended for use by NOAA/NWS users through an agreement between Vaisala and NOAA. > But, over night 6 of the 5 min files were > written, so I'm lost for an explanation. This almost seems like there is a problem on your local machine. Please run a 'notifyme' there to see if the receipt of the data is sporadic (which would indicate a problem getting the data), or if the machine is getting the data and the problem is writing it to disk. > I see those upper level files too, but have no idea what they actually > contain. OK. > I will change the request line as you suggested. The simplified request line that I mentioned previously should have nothing to do with your receipt of data. It will, however, help reduce the load on the machine the data is being requested from as the regular expression used is not as problematic. Cheers, Tom -- **************************************************************************** Unidata User Support UCAR Unidata Program (303) 497-8642 P.O. Box 3000 address@hidden Boulder, CO 80307 ---------------------------------------------------------------------------- Unidata HomePage http://www.unidata.ucar.edu **************************************************************************** Ticket Details =================== Ticket ID: DGC-319842 Department: Support IDD Priority: Normal Status: Closed