>From: McIDAS <address@hidden> >Organization: University of Puerto Rico >Keywords: 200008111642.e7BGgYN02913 McIDAS-X scripting Karli, re: switched feed to FSU >Oh I see, I just noticed that. We've been not getting any data during >the afternoon times lately, but the reason I changed to Alabama was that >even with FSU we had a similar problem. I didn't know that they hadn't >been receiving information recently. These things come and go. The reason I switched to FSU was that I wanted to verify that the changes I had made were working. The real bottle neck in your network connection seems to be somewhere close to you. The other day we did a number of traceroutes to breeze from our systems in Colorado, and packets got to Puerto Rico fairly fast. Once on the island, however, the ping times climbed dramatically. One test seemed to show that the big holdup was in 'centrix'. Is this the ISP for the university? I would have chats with the networking people on campus to see if there is something you can do (you being the university) to get better service. >You've got the green light to change over to ADDE. OK. I just added an action to your ~ldm/etc/pqact.conf to file NIDS products in ~ldm/data/nexrad/NIDS/JUA/... I also setup the NIDS.CFG file in ~mcidas/workdata to be able to find the raw NIDS products in that directory tree. I wish I could say that everything is working, but I see that breeze hasn't received any NIDS products from WSI since 01:52 on Aug 18: 8428533 -rw-rw-r-- 1 unidata 225088 Aug 18 07:31 AREA0108 8403082 -rw-rw-rw- 1 unidata 225088 Aug 18 05:13 AREA0112 8636682 -rw-rw-r-- 1 unidata 897280 Aug 18 05:10 AREA0275 8428532 -rw-rw-r-- 1 unidata 225088 Aug 18 05:10 AREA0107 8403369 -rw-rw-r-- 1 unidata 108 Aug 18 01:52 JUASTAT 8490999 -rw-rw-r-- 1 unidata 52 Aug 17 19:00 JUARESP Even at that, then next most recent product came in on August 17 at 19:00. >Aamos however, asks >if we could go back to the old system should problems arise. Right now, both decoding of the NIDS products and filing them is setup. This should be satisfactory. After things have proven that they are working correctly, we can shut off the converting of the NIDS products to AREA by nids2area. >You should >have soon about 4GB of free space to work with, if you need more, let us >know. breeze seems to have lots of disk space. It also seems like a lot of it is in use with files that could maybe moved off to tape: cd /user2/unidata ls -al total 72 drwxrwxr-x 5 ldm unidata 53 Apr 24 1998 . drwxr-sr-x 6 root sys 65 Dec 29 1999 .. drwxrwsr-x 15 ldm unidata 4096 Aug 7 19:44 data drwxrwxr-x 5 mcidas unidata 60 Nov 16 1998 mcidas drwxrwxr-x 2 mcidas unidata 32768 Aug 19 23:29 xcddata du -sk data 1078152 data This looks to me like 10 GB of disk being used in data and its subdirectories. >Once it's working I'll need to know what files can be deleted >(from the AREA scouring) so that we have more space. nids2area is creating AREA files in the 300 - 1100 range. Once it is turned off and you have transitioned to looking at the radar data through ADDE access, these files can be deleted. >You said that you >get higher resoltions through ADDE and we've seen that. What I was attempting to point out was: o McIDAS access through ADDE to data that is not located on your system o McIDAS support of the NOAAPORT GINI imagery through the GINI ADDE server that I added to McIDAS o the ability to look at a variety of data on systems of folks that are willing to cooperate with you (i.e. willing to allow you to look at data through their remote ADDE servers) Given your networking problems, it may be wise for Amos to think about looking for funds to purchase and install a NOAAPORT reception system. If you (UPR that is) got a two channel system (the Telecommunications Gateway (TG) channel (contains observations and model output) and the GOES-East channel, you would have all the data you would need and not have to fight the network bottle neck that you have been fighting for years. The cost of NOAAPORT reception systems is decreasing over time, so the prospects for getting one without a great financial hardship is improving. >We were >wondering as to the reason why AREA files have lower resolution, since >Aamos thought we were already getting 1KM images, while in reality they >seem to be 10km images. The AREA files that you are getting are sectors from much larger, and in the case of visible data, much higher resolution datasets. We send out VIS and IR sectors in 4 km resolution, and WV in 8 km resolution. The 4 km for the IR and the 8 km for the WV are as high a resolution as there is. The VIS channel on GOES, on the other hand, has 1 km resolution images. In one sense Amos was right. The floater products in the Unidata-Wisconsin channel can be in 1 km resolution. It depends on what was selected for the floater for the day. Again, the IR (10.7 um) and WV (6.8 um) channels are being sent in their maximum resolution already. Some of the composite products like the Mollweide composites are in even lower resolution. Perhaps Amos was thinking of these? Or, perhaps he was thinking that the display out of the Fkey menu was in full resolution; they are not. The images loaded out of the Fkey menu are blown-down (reduced) by a factor of two. This would make the 4 km IRs look like 8 km and the 8 km WVs look like 16 km. You can prove this to yourself by running some tests with the imagery in the broadcast. Compare: IMGDISP RTIMAGES/GE-VIS STA=SANU MAG=-2 REFRESH='EG;MAP H' with: IMGDISP RTIMAGES/GE-VIS STA=SANU MAG=1 REFRESH='EG;MAP H' >So will all of the feeds be ADDEized? or just NIDS products? Just NIDS for right now. Plus, the comment about the feeds being ADDEized is not correct. All that I am doing is changing the LDM action from decoding the NIDS products into AREA files to simply FILEing them in "raw" files. My NIDS ADDE server can then use the products just as they were received. This eliminates the conversion step at ingest, but adds an effective conversion step at display. The real objective is to be able to keep more images and maintain the numbers of them more easily. The other thing is that the Fkey menu actions for NIDS products should once again work for you since they were ADDEized in the 7.6 release. >Thank You, I will keep an eye on things this weekend and probably touch base with you again on Monday. 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.