>From: "James R. Frysinger" <address@hidden> >Organization: College of Charleston >Keywords: 200111061842.fA6Igt112242 LDM binary install Jim, >I've been doing a little work over the weekend.... re: Use the one for Solaris SPARC 2.7: > Did that. OK. re: setup pqact.conf entries for decoders > > Did that, as reported in last email. > > Went back to "Configuring User Accounts" in McIDAS online directions >and configured the account, frysingj, that I have on weather as a user. >I had already made the changes to my .cshrc. I skipped the bit about >the function and hot keys per our previous conversation. I used >~mcidas/admin/userdata to transfer the files indicated into >~frysingj/mcidas/data. Good. > Then I launched mcidas and did the two REDIRECT steps, Then I did the >BATCH step and exited. OK. > Then I took it for a spin, all of the above and this while sitting at >my home computer........ > > I'm able to launch GUI from the command line, but not as a command >argument for launching mcidas. That is, from a shell, mcidas -c 'GUI' >did not work, but once mcidas launched, I could type in GUI on the >command line and get the GUI window, which replaces the image window. I >found that, as expected, operating mcidas remotely from my frysingj >account while at home via ssh is not exactly speedy! Lottsa bits have >to pass through the ports for those displays. So, you were running the sesson on your Sun with the DISPLAY back to your home machine it seems. This will be slow no matter what kind of bandwidth you have at home. A more efficient setup would be to run McIDAS on your home machine and simply access data remotely. >That's why I'm wondering >if it wouldn't be an advantage to use a mcidas/adde setup here at home >(already partially installed) and let my adde here at home get a feed >from the adde at weather.cofc.edu. It would be a great advantabe to run the application locally and get the data remotely. With the MCGUI, you have a fairly easy interface that allows changing who you get data from. This is how I run at home.. >We're not inclined to want to NFS my >home computer on the department's *nix net! No need for NFS with McIDAS. >Then, hopefully, I could >set up a qualified 'feedme' and get the particular types of files that >I personally use fed to me continually by weather. (I leave my home >computer on continuously and pay for business cable modem traffic >levels.) Why get fed the data when you can access it from remote servers any time you like? > Meanwhile, regarding my remote use of the McGUI, I had mixed success. I would expect this if your X display is sent over your connection. Running it locally would be the ticket. >I was finally able to plot a model contour (ETA 00h, I seem to recall) >on a map of SC in frame 1. Then when I tried to build a similar one for >the next forecast period in frame 2, it hung. In fact, I had a lot of >trouble with the McGUI hanging on me. As a result of this experience, I >would recommend a command that could be typed in the command line to >kill the McGUI so that the user could relaunch it or go back to the >vanilla image window. It shouldn't be MCGUI that is hanging, but, rather, the application that is being run. And this will timeout after the ADDE timeout period (nominally 120 seconds or can be changed through the setting of the ADDETIMEOUT environment variable). >Usually, when McGUI hung, the command line still >worked but the menu bar on McGUI did not. Hmm... >Without that I had to exit >McIDAS and relaunch the whole program. Usually, when I did that, the >command line/text window exited cleanly but the McGUI window(s) did >not. I had to go back to my temrinal window and kill those mcwish >children. Again, these are all symptoms of running the display of the application to a remote machine. If run locally, MCGUI will work nicely. > The McGUI window allowed me to do some exploring of grid data >resources after I figured out how to use the GRID window. This and one comment above sounds like you were using the SSEC GUI interface, not the Unidata MCGUI one. I have not yet added GRID file access to MCGUI, so you must be using GUI. >But the IMAGE >selection under Display never launched a similar IMAGE child window and >I could not display satellite data from that. This verifies that you are using the GUI, not MCGUI. > On the textwindow front, I tried to explore what data was available to >me. The GINI stuff, coming in remotely instead of from our adde, seemed >OK, but I ran into some other problems on the weather.cofc.edu adde >datatypes. Here are a couple that I jotted notes on: > >DSINFO GRID RTGRIDS >[list of various products appeared] >GRDLIST RTGRIDS/ALL.ALL --> >GRDLIST: no grid found matching search conditions >likewise for AVN.ALL and ETA.ALL Try: GRDLIST RTGRIDS/ALL.ALL FORM=FILE If you get nothing while pointed to your own machine, then it means that the GRID decoding is not turned on, or something is amiss with your ADDE services. I tried this myself from my home machine and got: GRDLIST RTGRIDS/ALL.ALL FORM=FILE GRDLIST: No Data Found GRDLIST - done GRDLIST failed, RC=2 So, there is a problem. I will look at this when I get into work. >DSINFO IMAGE RTIMAGES >[list of various products appeared] >IMGLIST RTIMAGES/GE-VIS.ALL >IMGLIST: no images satisfy the selection criteria Ditto. >DSINFO IMAGE RTNEXRAD >[list of various products appeared] >IMGLIST RTNEXRAD/NVL.ALL >IMGLIST: Use ID= to specify NEXRAD station ID; ID=LIST to list >available stations >IMGLIST RTNEXRAD/NVL.ALL ID=LIST >IMGLIST: There are no images that meet the selection criteria I don'b velieve that your NEXRAD ingestion/filing is setup yet. Given this, the message above is what I would expect. > The above seems to indicate to me that McIDAS is not finding stuff on >our adde server, but our /export/home usage grew by quite a bit when I >added those edited decoder lines to pqact.conf, which would tell me >that data is going in there somewhere. The NEXRAD lines would be FILE actions. I will take a look a little later. >>From address@hidden Mon Dec 10 09:20:12 2001 re: If ldmadmin watch doesn't show anything, you aren't receiving anything. The other thing to try is notifyme: > That shows stuff coming in but I didn't see any decoder action like I >remember seeing last year. But ldmadmin watch does not show decoding actions. For this, you would have to do a tail on the end of the LDM log file: ldmadmin tail And, this will not show XCD decoder info since those decoders are running over in McIDAS land. It should show ldm-mcidas decoder messages, however. re: notifyme -vxl- -o 3600 > >shows the incoming and a bunch of extra info that I take to be the >'echo's of decoder action. No decoder actions should show. Notifyme just shows products getting written into the queue. >Lottsa stuff coming through the wire and >current stuff in my queue. OK. re: need to run mcscour.sh from cron > Will do. Again, I will look in on weather a little later. 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.