>From: "Klein, William" <address@hidden> >Organization: Valparaiso >Keywords: 200310061909.h96J98k1027137 McIDAS-XCD mcscour Bill, >I believe we are only gathering GEMPAK data (haven't hub'ed in the new >pqact.conf yet) and McIDAS. Got it. I found that the disk space was being used by NEXRAD Level III products which weren't getting scoured correctly. After doing some cleanup, /var/data now has 25 GB of space. The real culprit appeared to be a misspecification of PATH in ~ldm/util/prune_nexrad.csh: /home/ldm/decoders was being added to the PATH, but it should have been /home/ldm/util. I corrected this problem and scoured the various ~ldm/data/nexrad/NIDS subdirectories "by hand" to get things going again. I also removed the /var/data/mcidas directory since it was archaic (data was very old and not being updated), and removed very old files in /var/data/ldm/mcidas (which were remenants of improper scouring). I think data decoding should now work correctly, but there is a possibility that some McIDAS datafiles were damaged when the disk ran out of space. This will have to be monitored by someone at Valparaiso (by running McIDAS routines that access the POINT data (sfc, upper air, etc.)). Please let me know if problems are found. Also, we got an email from Wenxian Lu <address@hidden> regarding a problem decoding data into GEMPAK format. I sent him a note telling him that the problem was most likely (for sure) due to /var/data being full. He will have to keep an eye on the GEMPAK decoding to let us know if does not start working again. Cheers, Tom
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly 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.