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: David Fitzgerald <address@hidden> >Organization: Millersville University of Pennsylvania >Keywords: 200108271943.f7RJhW128098 McIDAS-XCD rapid access Dave, Sorry that I couldn't get back to you yesterday, but I was in the final stretch of selling my house (moving and then closing, phew!). re: I ran smack dab into a brick wall >Now you know haw I feel. Yes, I could really relate to your frustration. >My gempak decoders are working properly. I am >getting current data and can view it in garp and nmap just fine. OK. I just logged onto twister and took a look at XCD decoding of files for the RTPTSRC and RTGRIDS datasets. Apparently, things started working correctly beginning for RTPTSRC files with 0Z today. I have _NO_ explanation for this, but I am of the mind to not worry about it unless the decoding goes south again. The GRID decoding appeared to be working correctly on Monday; sorry I didn't mention this. One thing that I did do was comment out the scouring of the McIDAS data files from ~ldm/etc/scour.conf. This is not needed since your McIDAS data is being scoured by the ldm-mcidas/bin/mcscour.sh invocation in your LDM user's crontab file. By the way, I get pretty good response from your ADDE remote server for RTPTSRC, RTGRID, and RTIMAGES datasets. Has your network bandwidth increased recently, or are Millersville students not back yet (or not bogging down the network with the demise of Napster)? Please let me know if you see a reoccurrance of the decoding problems. I will continue to peek at your data via ADDE from time-to-time from here. Also, I _think_ that I noticed you still converting WSI NIDS images into McIDAS AREA files; I see lots of files with AREA numbers above 300. If this really is the case, you can save a good bit of CPU by: o not converting the imagery o providing ADDE access to the raw files directly If you are interested in pursuing this, please let me know and I can help you set it up. I would guess that you are already using the filed NIDS products withing GEMPAK/GARP/NMAP. McIDAS can use the same hierarchical directory structure as GEMPAK and provide ADDE access to those data. One last thing. If your network bandwidth has improved significantly, would you consider joining the list of cooperating ADDE server sites? What this would mean in practice is that you would allow McIDAS and MetApps users to access data off or your ADDE remote server. How much this may be done is unknown, but I suspect that it would not be that much. The idea is for McIDAS sites to act as each other's realtime data "archives". If your feed was hosed for some reason but your network connection was still OK, you could access someone else's data holdings. If they were in the same boat, they might come to you for realtime data access. Please give some thought to participating in this endeavour and get back to me. Tom