>From: "Karli Lopez (McIDAS)" <address@hidden> >Organization: University of Puerto Rico >Keywords: 200002010754.AAA03412 datastreams ROUTE PP BATCH LDM Karli, >Alright, the Sat/Topo imagery is being generated once again! At least >it seems to since the new dates are shown in the routing table. I >checked lwtoa3 again just to be sure, and the files are there. It >seems it just was a batch.k misconfiguration problem (I wasn't aware we >needed to make such changes, I know now...). Sounds good. re: discontinued products >Yeah that's what I meant. We've never gotten Administrative Messages >in the first place. And what about that Wind Profiler? (this is just >out of curiosity) The FSL wind profiler data is avaiable in hourly summary and 6-minute forms throught the FSL2 feed in the IDD. The ldm-mcidas decoder, proftomd, can decode either/both of these products into McIDAS compatible MDXX files. The profiler network is basically in the central portion of the US, so it would probably not be of much interest to you. re: North American and Global Initialization GRID files >and so we will never see them again...? (well what I mean is are there >alternate sources?) The IDD contains all of the model data from NCEP. Instead of just looking at these two small pieces of the full data set, you can decode all of it into McIDAS GRID files. The thing that is different is that the ordering of the grids in the XCD GRID files is not set. The Fkey menu actions for plotting gridded data used to rely on that ordering. With the conversion to ADDE, the Fkey menu no longer needs the specific ordering. The MCGUI, on the other hand, was not ADDEized since ADDE was not finished enough to make the change. Now, if you wanted to, and if you are decoding all of the model data in the IDD using XCD, you could run the UWGRID command to recreate the North American and Global initialization GRID files locally. This would allow you to keep working just the way that you were before the products were removed from the datastream. In order to facilitate this, I wrote the Bourne shell script, uwgrid.sh. This is simply a wrapper around the UWGRID command (like batch.k is around BATCH). uwgrid.sh gets installed in the ~mcidas/workdata directory. You should look through it to see what you need to do in order to create the NA and Global GRID files. The other alternative is to change a couple of McIDAS environment variables and point at the RTGIRDS/NGM and RTGRIDS/AVN datasets. After doing this, and assuming, of course, that you are decoding the grids with XCD, the Fkey menu will work directly off of the new files. I can give you more details if you decide to go down this route, or you can look up information in the online McIDAS Support email archives: Unidata McIDAS-X Home Page http://www.unidata.ucar.edu/packages/mcidas/mcx Select the 'Support archives' link in the left hand side frame under Support. Use uwgrid, ngm, and avn for search keys. >As for the this problem I suspected ADDE would be involved, and I had >wondered why it was taking so long for the image to load, and why I >would get up to date Topo/Sat images. You have to admit that this was pretty cool notwithstanding the time it took to load the images. Your requests were coming all the way to Boulder and being fulfilled without you even knowing it (modulo the slowness factor). >I have not much with setting up >ADDE so the cause for the problem was both the server they were setup >for and a misconfigured ADDE. I figured that the problem. >Calling DATALOC I got the following output: > >DATALOC LIST >------------------------------------------------------------------------------ > ------------------------ > >Group Name Server IP Address >-------------------- ---------------------------------------- >BLIZZARD 144.92.109.163 >MYDATA <LOCAL-DATA> >PLANET <LOCAL-DATA> >RTGRIDS <LOCAL-DATA> >RTIMAGES ZERO.UNIDATA.UCAR.EDU >RTNIDS <LOCAL-DATA> >RTNOWRAD <LOCAL-DATA> >RTPTSRC <LOCAL-DATA> >RTWXTEXT <LOCAL-DATA> >TOPO <LOCAL-DATA> > ><LOCAL-DATA> indicates that data will be accessed from the local data director > y. >DATALOC -- done OK, a couple of things here First, you were pointint to our machine, zero, for the realtime images. Second, you were pointing to a machine at SSEC for access to the BLIZZARD datset. >DATALOC ADD RTIMAGES LOCAL-DATA >DATALOC: Problem writing strings, probable setup error This is a problem. It seems to be telling us that ~mcidas/data/ADDESITE.TXT is not writable. What do you get when you do a: DMAP ADDESITE.TXT This will tell us exactly where this file is. If it is not in ~mcidas/data (I am assuming that you are doing this as the user 'mcidas'), then you have setup problems. Also, what is the setting for MCTABLE_WRITE in your Unix session? Each user can have a private copy of a file named MCTABLE.TXT and can share any number of other files through settings of his/her MCTABLE_READ environment variable. This variable contains a list of fully qualified file names to search through when trying to figure out which server to go to for a particular dataset. The recommended setting for the user 'mcidas' is: MCTABLE_READ="${MCDATA}/MCTABLE.TXT;/home/mcidas/data/ADDESITE.TXT" MCTABLE_WRITE="/home/mcidas/data/ADDESITE.TXT" MCTABLE_READ says that the user 'mcidas' reads both ${MCDATA}/MCTABLE.TXT and /home/mcidas/data/ADDESITE.TXT to find out where to go to fulfill a data request. $MCDATA in the user 'mcidas' case should be /home/mcidas/workdata. MCTABLE_WRITE says that when the user 'mcidas' does a DATALOC, the information should be written into home/mcidas/data/ADDESITE.TXT. The error you got when trying to do this seems to indicate that this file is unwritable for some reason (or your MCTABLE_WRITE setting is incorrect). Users other than 'mcidas' have the following settings for their MCTABLE_READ and MCTABLE_WRITEs: MCTABLE_READ="${MCDATA}/MCTABLE.TXT;/home/mcidas/data/ADDESITE.TXT" MCTABLE_WRITE="${MCDATA}/MCTABLE.TXT" These look the same as for the user 'mcidas' except that MCDATA for the non-'mcidas' user will be ~user/mcidas/data, a directory local to that user's account. >> What you need to do is see if your datasets are setup: >> >> <login as 'mcidas'> >> <start a McIDAS-X session> >> DATALOC LIST <- see who you were getting images from >> DATALOC ADD RTIMAGES LOCAL-DATA <- get them locally >> DSINFO IMAGE RTIMAGES <- see if they are setup >> >> If they are setup, then do the following: >> >> IMGLIST RTIMAGES/GE-VIS.ALL >> >> You should get back a listing of all of the GOES-East VIS images on >> your system. >> >> If you do not get back a listing, or if the files are all old, then the >> ingestion/decoding of your imagery and/or setup of your ADDE datasets >> is suspect. >To be honest I don't know what the BLIZZARD dataset The BLIZZARD dataset is the one that goes along/is used by the online Learning Guide: http://www.unidata.ucar.edu/packages/mcidas/mclearn/learn_guide.html >(is it Radar or NLDN related). Nope. The dataset has satellite imagery, point source, and gridded data. >Anyway I couldn't change the information with RTIMAGES >so I know somethig's still wrong with the configuration. Check for write permission problems. >So far we had >the mcadde account created, and ADDE partially set-up for out previous >version of McIDAS (7.5 I think). We have the account running, as well >as the server, but all I did for setup this time was run the uninstall, >make and install processes. I will be going to review and apply if >necessary the Account configuration steps to make sure I didn't miss >anything. OK, a quick 'telnet breeze.uprm.edu 500' shows that the port is setup correctly. A quick DATALOC from my machine shows that the server setup is not complete/correct: DATALOC ADD RTIMAGES BREEZE.UPRM.EDU Group Name Server IP Address -------------------- ---------------------------------------- RTIMAGES BREEZE.UPRM.EDU <LOCAL-DATA> indicates that data will be accessed from the local data directory. DATALOC -- done DSINFO IMAGE RTIMAGES No Datasets found of Type: IMAGE in Group: RTIMAGES DSINFO -- done >I do have another semi-related question: For all of the accounts that >we have previously set up under McIDAS 7.5 (or 7.1) should we redo the >Redirections (REDIRECT REST LOCAL.NAM, etc.) and BATCH "MYDATA.BAT >configuration steps? You will only have to do these if the locations of McIDAS data files changed. I suspect that they have not changed. The setup for the ADDE remote server shouldn't take much time. The steps are detailed in: Installing the McIDAS-X ADDE Remote Server http://www.unidata.ucar.edu/packages/mcidas/mcx/adde_mcx.html The gist of the configuration is: o the user 'mcadde' is kind of an alias for the user 'mcidas': it shares the same HOME directory, but you should not be able to login as it o the file ~mcidas/.mcenv sets up environment variables needed for McIDAS sessions. This file is read by the remote ADDE server processes o 'mcadde' finds McIDAS files exactly the same way that 'mcidas' does; this is true since 'mcadde' is essentially 'mcidas' (see above) >Thanks again Tom. It sounds like you are almost finished; hang in there. 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.