>From: Thomas Mote <address@hidden> >Organization: U. Georgia >Keywords: 200012282251.eBSMpko24860 McIDAS-X 7.70 ADDE Tom, re: how to setup directories so that can have current and archived data available >I'll think about this. For now, I may cut it to three days of satellite >imagery and just leave it all in the same directory. I want to make sure I >have at least one full 24-hour period available. I agree with this approach. I am thinking of a moving 24-hour (or whatever length makes sense) "window" into a larger set of data (2, 3, 4, 5... days). How to do this efficiently is the trick. >BTW, what is the easiest >way to make this imagery available? I suppose I could add something on the >function key menu. Any suggestions? I will be immersing myself into a rewrite of the Unidata GUI for McIDAS in the next couple of months. After that, the GUI (MCGUI) will be able to "point" at any server for any supported data type (IMAGE, POINT, GRID, TEXT) and display/analyze/copy/etc. The nice thing about this approach is that when one's data is stale, but internet connections are viable, one can simply point at another server and keep working. It might be wise for me to jam together the Fkey menus necessary for access of GINI data and put it in an addendum. I will chew on this for the next couple of days. >Thanks for all the fixes on the CFG file. I did change a couple of >directories (as you noticed) when I made the other changes. I wasn't sure >how to specify the filename filter. As long as it works, I'm happy! You are welcome. Some of the changes were caused by directory name fluidity, but most were caused by my fat-fingering at the keyboard. >Regarding a public announcement of the availability of the data. I'm >willing to do that, but there are a couple of things I should ask/tell you >about. OK. >First, I know the NIDS data is supposed to be available on NOAAport very >shortly. Yes, starting tomorrow! >Our NOAAport vendor will provide us with the software necessary >to ingest it (may not require any modifications, not sure). We only have >a one-channel system, but we can automatically switch between channels. If >the NIDS data is not available via the IDD, It will be. We are establishing a floater stream much like the one from WSI. Also, individual sites will be able to request particular stations' products from the top level IDD nodes. Finally (but not least), McIDAS sites will be able to display any/all stations by pointing at ADDE servers that have all of the data all of the time. >I may "channel surf" hourly to >get some satellite imagery and some NIDS data. I would leave everything >configured as it is now, there just wouldn't be as many images. If a >sufficient amount of NIDS data will be available on the IDD, then I >will just leave my NOAAport system pointed to GOES East. What is the plan >for putting NIDS on the IDD? (Feel free to point me to a web page if this >information is already posted.) There have been numerous emails to ldm-users about the plan for IDD distribution of NIDS (NEXRAD Level III product) data. The following is the body of one of the more recent announcements: Date: Fri, 29 Dec 2000 09:58:29 -0700 From: Anne Wilson <address@hidden> Organization: UCAR Hello LDM Users, After January 1, unencrypted NOAAPORT NEXRAD Level 3 data will be available via the Internet Data Distribution system. In a previous message we told you about our plan to distribute the NEXRAD data: http://www.unidata.ucar.edu/packages/ldm/receivingRadar.html In particular, we have drafted a new routing scheme for the NEXRAD data that uses only two tiers. It can be seen at http://www.unidata.ucar.edu/projects/idd/nexradFeed.html Please look there to see which first tier site you should use as your NEXRAD feed. Also, we have prepared a page to help you get the NEXRAD data. See http://www.unidata.ucar.edu/packages/ldm/feedtypes/howto-nnexrad.html for detailed information about getting and using the data. Please proceed slowly in requesting NEXRAD data, because if you request all of the data as soon as it is available, there is a real possibility of overloading your own site as well as delaying data to other IDD sites, since the NEXRAD data is a significant increase in the number of products and volume of data already carried on the IDD. We recommend that sites start by requesting the NEXRAD floater feed and at most three other sites until we have a chance to evaluate and adjust the routing to balance the load among participating IDD sites. The encrypted, uncompressed data is currently available on the NEXRAD feed and is already flowing to several first tier sites. You can add your request line now to start receiving the data when it becomes available at your upstream feed. If you have any questions, please first read the information available. Many questions are answered there. If you can't find the answer to your question in the material we have provided, send email to address@hidden We also want to express our appreciation to top-level source sites and first-tier sites for agreeing to participate in the NEXRAD data distribution, giving up some of their network bandwidth, computing resources, and time during the holiday season to reconfigure their LDMs to make NEXRAD data available to other IDD sites. In particular, we want to thank: Harry Edmon Eric Horst Eirh-Yu Hsie Mark Laufersweiler Bob Leche Jeff Masters Bill Noon Art Persons Pete Pokrandt Larry Riddle Jerry Robaidek Clint Rowe Gilbert Sebenste Paul Sirvatka Bryan White David Wojtowicz for their help. Wishing you all a wonderful new year with lots of good quality data! --Anne --Russ >Secondly, there is a 50/50 chance we will be purchasing a 2- or 3-channel >NOAAport system in the next six months. I should know in the next few >weeks whether we will get the go ahead. We would be willing to make this >data publicly available as well, and I may also have some funds for >support staff. The purchase would be from the same vendor, so presumably >we wouldn't need to change the way things are configured. Excellent! It would be very generous of you to help other Unidata sites by providing access to more of the NOAAPORT conveyed data, especially the satellite imagery and NIDS products. >Finally, we have had some network connectivity problems in our building. >Cacimbo is attached to a 100Mbit hub, which is directly connected to the >building fiber network and then the campus fiber optic network, bypassing >the old thick ethernet in most of our building. However, they are having >problems with the new system and we have found a number of occasions where >the connectivity for machines on the fiber optic network is slower than >the old broadband. It was probably quite fast today as nobody was on >campus. I hope it stays that way and they have the bugs worked out, but I >just thought I should mention it. The connection was very fast yesterday. Loading images from cacimbo to my home machine was very fast (ADSL is nice when you are close enough to the phone switch). >Thanks again. You are certainly welcome. Two last comments: o Since you only have the GOES-East NOAAPORT channel, I added/created a new ADDE dataset called GINIEAST. The components of this dataset are the same on your machine as RTGINI, but the name is more representative of what you actually have. Following this example, I created two datasets from the original on the ADDE server that we maintain in the main machine room of NCAR, adde.ucar.edu. Since that machine has both GOES-East and GOES-West data, it made sense to have one dataset called RTGINI. It now has three: RTGINI (all of the GINI data), GINIEAST (for the NOAAPORT channel 1 data), and GINIWEST (for the NOAAPORT channel 2 data). I have to say that there is a lot of redundancy in the elements of the datasets since there are some products that are broadcast on both NOAAPORT channels 1 and 2: CONUS, CONUSCOMP, and the imagery products (LI, PW, SFCT, CTP). By segmenting the datasets, a site can point at one ADDE server for GOES-East data and another server for GOES-West data. This will help balance the ADDE load when more and more sites start taking advantage of its services. o Second, I noticed that your XCD surface decoding was not working correctly (lots of 80 F temperatures in regions that should be in the 20s). I took the liberty of attempting to fix the problem by doing some XCD reconfiguration. A quick SFCLIST of KDEN for the past 24 hours pointing at cacimbo looks reasonable. Also, a 24 hour listing for Gilette, WY (KGCC) looks like the problem was fixed: %sfclist.k KGCC 24 Day Time StCo Stn T Td Dir Spd Gus AltSet Vis Weather Ceil hhmm id [F] [F] [ kts ] [mb] [mi] ---- ---- ---- ----- --- --- --- --- --- ------ ----- -------- ----- 30 2000 WYUS KGCC 86 5/000 30 2100 WYUS KGCC 86 5/000 30 2155 WYUS KGCC 26 19 000 0 1018.3 10.00 5/080 30 2255 WYUS KGCC 25 19 090 5 1018.6 10.00 8/085 S 30 2320 WYUS KGCC 310 24 6.00 5/080 30 2355 WYUS KGCC 21 18 090 3 1019.0 10.00 5/080 31 0055 WYUS KGCC 17 14 190 3 1019.3 10.00 5/080 31 0155 WYUS KGCC 19 16 040 4 1019.6 10.00 8/080 31 0255 WYUS KGCC 18 15 210 3 1020.0 10.00 8/085 31 0355 WYUS KGCC 19 16 000 0 1020.7 10.00 8/080 31 0455 WYUS KGCC 19 15 000 0 1020.7 10.00 8/080 31 0555 WYUS KGCC 17 15 230 4 1021.0 10.00 5/085 31 0655 WYUS KGCC 10 8 190 3 1021.3 10.00 31 0755 WYUS KGCC 7 3 170 3 1021.0 10.00 31 0855 WYUS KGCC 4 0 000 0 1021.0 10.00 31 0955 WYUS KGCC 7 4 000 0 1021.3 10.00 31 1055 WYUS KGCC 3 -1 000 0 1021.0 10.00 31 1155 WYUS KGCC 2 -1 000 0 1020.7 10.00 31 1255 WYUS KGCC 3 -1 000 0 1020.7 10.00 31 1355 WYUS KGCC 3 0 000 0 1020.3 10.00 S 31 1409 WYUS KGCC 3 1 110 3 1020.3 10.00 5/006 31 1455 WYUS KGCC 5 1 000 0 1019.6 10.00 5/006 S 31 1504 WYUS KGCC 7 3 330 4 1020.0 10.00 31 1555 WYUS KGCC 12 9 000 0 1019.6 10.00 31 1655 WYUS KGCC 17 14 000 0 1020.0 10.00 5/050 31 1755 WYUS KGCC 26 22 020 3 1019.6 10.00 31 1855 WYUS KGCC 28 22 000 0 1019.0 10.00 Number of reports = 27 sfclist.k: done You can see that the Ts before my mods were bogus (86 F and no Tds at 20 and 21 Z) and the Ts after my mods look reasonable. I will do some plots/contours on Tuesday when I am at a place where I can crank up McIDAS. Here's to a healthy, happy, and bright New Year! 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.