[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20011210: McIDAS vis-a-via Solaris 7/8 (cont.)



>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