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: "Matthew J. Rosier" <address@hidden> >Organization: UNCA >Keywords: 200307202337.h6KNb1lo026615 McIDAS ADDE DATALOC BLIZZARD Hi Matt, re: McIDAS not being able to "see" the BLIZZARD dataset >The mcidas issue is actually not with UNCA's McIDAS, which at last check is >working fine, but rather trying to set up mcidas on my personal linux box. OK. >As far as you logging in to my box remotely, well, for some reason I cannot >ssh onto the machine from another PC, but this MIGHT have something to do >with the fact that the machines are on a router, but I don't see why that >would screw up my ssh. > >Actually, perhaps the router is not passing on port 22 traffic, because a >netstat -la | grep ssh yields: > >tcp 0 0 *:ssh *:* LISTEN >unix 2 [ ACC ] STREAM LISTENING 4275 >/tmp/ssh-XXZb3tLK/agent.1456 > >Hmmmmmm. If this is a router under your control, you can set it to pass port 22 traffic through (exactly how is dependent on the router itself). The other thing to check is your /etc/hosts.allow and/or /etc/hosts.deny files. Make sure that there is no rule that explicitly denies ssh access to all outside machines. One thing to check. Can you do a 'telnet adde.ucar.edu 500'? (you will have to do a CTRL-C to stop this). If yes, can you also do a 'telnet adde.ucar.edu 503'? If you can NOT do the telnet, then your access to adde.ucar.edu is being blocked by something. By the way, you can grab the BLIZZARD training set and install it on your own machine: <login as 'mcidas' to your machine> cd mcidas/data/tutorial ftp ftp.unidata.ucar.edu <user> umcidas <pass> XXXXXX cd data/tutorial binary get learn.data.tar.Z quit tar xvzf learn.data.tar.Z Next, you have to setup the BLIZZARD ADDE dataset. <start a McIDAS session and do the following from the command line> DATALOC ADD BLIZZARD LOCAL-DATA <- must be done first! REDIRECT ADD AREA8* "/home/mcidas/data/tutorial REDIRECT ADD MDXX8* "/home/mcidas/data/tutorial REDIRECT ADD GRID8* "/home/mcidas/data/tutorial Test to make sure that you can see the files: DMAP AREA8 DMAP MDXX8 DMAP GRID8 If not, check your REDIRECTions Next, create the ADDE dataset BLIZZARD: BATCH BLIZADDE.BAT Test to make sure that you can access the various pieces of the dataset. DSINFO IMAGE BLIZZARD IMGLIST BLIZZARD/IMAGES.ALL At this point, if all things worked you should be good to go. >You mentioned the non-existence of mctable.txt as being a good thing, Yes. Again, the setup for the user 'mcidas' is special. 'mcidas' is to be thought of as 'root' for McIDAS. This is so much the case, that the SSEC distribution of McIDAS does not even allow the user 'mcidas' to run McIDAS! I change that in the Unidata distribution so that the user 'mcidas' can do things on behalf of all other users. Operating in the 'mcidas' account assumes that the user really knows what s/he is doing (just like being 'root' in Unix/Linux). The ~mcidas/workdata/MCTABLE.TXT file for 'mcidas' is only updated if 'mcidas' creates and edits it manually, OR if that same user did not follow the instructions on how to define MCTABLE_WRITE. >but I >suppose there is still no one solution to the problem, else you wouldnt need >to access my machine remotely? The failure of your McIDAS session to see the BLIZZARD dataset is not something that occurs frequently, or, quite frankly, at all _unless_ there is some sort of network or McIDAS configuration problem. This is why nothing is jumping to my mind on what could be the problem on your machine. >Alex is a good guy a great professor, quite smart. Yup, I knew all of that :-) >I assume you know (or >know of) Leigh Orf, he was more of our Linux guru, but has just left for >Central Michigan University. Yes, I had many email exchanges with Leigh. >As far as the login info for McIDAS on storm2 incase you need it, well, I'm >still trying to remember it, I thought the login info was >unca-mcidas/mcidas2002 but that doesnt seem to be working. If I had the 'mcidas' login to storm2, I would at least upgrade the distribution to the latest addendum, v2002b. In a week or so, I would upgrade storm2 to the new McIDAS release, v2003 (a work still in progress). v2002b+ contain a fix for accessing upper air data from an ADDE server running on Linux. By the way, Leigh was the first person to find this problem. It was because of that problem that Leigh and I exchanged email. >Anyhow, one of >the main reasons I am trying to get McIDAS up and running on my personal >Linux box is so I can become more familar with it's command interface, I had >no idea McIDAS was so powerful until I started an internship with >Raytheon/NESDIS Forecast Products Development Team. All the derived product >imagery and GOES sounder stuff is generated and run through McIDAS. Not only that, but all of the images in the NOAAPORT broadcast are created using McIDAS. The command line interface may be pretty arcane, but the underlying functionality is huge, so many users bite the bullet and learn how to run the package. >Thanks again Tom, No worries. Tom -- +-----------------------------------------------------------------------------+ * Tom Yoksas UCAR Unidata Program * * (303) 497-8642 (last resort) P.O. Box 3000 * * address@hidden Boulder, CO 80307 * * Unidata WWW Service http://www.unidata.ucar.edu/* +-----------------------------------------------------------------------------+