20000710: ROUTE PostProcess BATCH processing and setup (cont.)

>From: "James D. Marco" <address@hidden>
>Organization: Cornell
>Keywords: 200007062021.e66KLJT26042 McIDAS-X ROUTE PP BATCH ADDE

Jdm,

>       I didn't work on McIDAS at all this weekend...well, if you don't
>count monitoring operations. 

OK, so the ADDE stuff was setup correctly to begin with.  Like I said,
I have been able to access imagery, point source (e.g., surface 
temperatures), and "text" (RTWXTEXT dataset one instance of which
is fronts) from machines here in Boulder (at work and at home).

>       Back at it Monday Mourning. 
>       The game plan I outlined is more or less, just stuff having 
>to do with Unidata data streams and programs.  MM5 got mixed in 'cuz
>we have a modified high-resolution model for Lake-Effect research that
>requires the LDM/GEMPAK ETA model run as an initializer. More below...

OK.

re: C shell things to worry about with McIDAS-X

>Yup.  I knew this.  The problem is not with McIDAS or LDM, rather
>administrative. There are about 130 students (undergrad and grad) plus 
>faculty. Everyone (with two exceptions) uses bash. I set up the new-user
>skeleton to include the McIDAS stuff...$HOME/mcidas/data...and the .bashrc
>with McIDAS pathing so that a new account automagically is configured for
>McIDAS. To retrofit all existing accounts, I added MCDATA, MCPATH, etc. to
>the System bashrc in the /etc directory.  This results in double pathing to
>all the McIDAS stuff, it worked but was pretty sloppy, as you saw. 
>As per you recommendations, I want to clean up the data pathing (complicated 
>enough without my hacking) for McIDAS and LDM.  If they don't use the 
>/etc/bashrc file, then they will NOT get the double pathing. Csh will not
>use the /etc/bashrc, it uses /etc/csh.cshrc.  This allows me to set up 
>separate environments for administration (McIDAS, LDM, GEMPAK) and users.  
>Good idea just on principles. Soo, your recommendation of csh for installs
>is correct and I should NOT have converted to bash.

OK.  Got it.

>I haven't used csh for about 9 years (ksh and, later, bash), but I did use 
>it extensively (on BSD/Sun) before that, soooo, it's not a big deal.

re: question I didn't understand
>The output from our high-resolution MM5 model is in .gem format.  Can I
>encrypt this into a local LDM stream(do-able I think)

Yes, I think so.

>and, possibly
>display/distribute through McIDAS, rather than GEMPAK? (I'm thinking of
>the MOS/FOUS in McIDAS.)

Hmm...  It might take some work.

re: operation in 24-bit Xwindows
>Exactly.  Worse, the Enlightenment Xmanager consumes a LARGE color map,

Right.  But with 24-bit displays, who cares.

>I
>think there are only 63 colors available for GEMPAK sessions once you are in 
>X.

Right.  You can specify how many colors are to be used with GEMPAK so that
it will come up in environments with a lack of colors.  KDE, on the other
hand, doesn't consume so many colors, so it is easier to run GEMPAK/GARP
in.

>Garp won't even start up, though some other programs do start. Of course,
>the command lines work, you just can't see anything.

I would tell you how to get things working if I knew.  Our GEMPAK support
guy (Steve Chiswell) is out of the office until Wednesday.  I'll touch
base with him when he gets back.

re: Have you been working on this this morning?
>Nope. For some reason, Fronts/Weather watch boxes are intermittent, but
>I suspect some undefined interaction problem(s) that you may have solved
>with the ROUTE fix. 

I have noticed that the front reports themselves can be intermittant.
It could be that you are just seeing their lack in the IDD.

re: TCP wrappers
>I opened your IP numbers.  Some stuff goes through the wrappers anyway.(I
>don't know about McADDE, just starting to look seriously at it.)

As far as I understand TCP wrappers, you would have to modify the mcserv
and mccompress entries in /etc/inetd.conf to run the wrapper and then
configure the wrapper layer to allow/disallow machines by IP mask.

re: crankup a McIDAS session and take a look at RTGINI data at UCAR

>Uhhh, it didn't work.  
>       DATALOC is failing I think
>       (No data sets of type image.....)
>       Work on it later, some support issues have come up...

DATALOC can fail if the IP address for the machine can't be determined.
If this is the case, substitute the real name of the machine for the
alias that I provided:

DATALOC ADD RTGINI motherlode.ucar.edu
DSINFO I RTGINI
IMGDISP RTGINI/GE1KVIS STA=KBMG ....

re: lack of stretch tables for CIMSS products

>OK.  That's why I couldn't find them.

re: schedule for 7.7 release may slip
>OK...won't hold you to it...;)

I just sorted out one of the problems I had run into on DEC OSF/1.
The problem was in some new code (naturally) from SSEC that had
implicit assumptions about the length of words (OSF/1, True64 are
8-byte OSes).

re: problems with McIDAS GUI
>Will keep you posted.  I'll gen some errors for you.

I got your second message.  More on this below.

re: running on NT using Interix and Exceed

>Yup.  I have an older copy of Interix and Exceede, of course.  My major
>concerns with Interix are:
>       Interix is a FULL UNIX suite of functionality overlaid on the 
>NT kernel.  This logic escapes me.  The UNIX kernel is smaller and more
>flex able.  The resulting indirections result in less than efficient 
>implementations on NT...sort'a contradiction of UNIX philosophy. Also, 
>an immature product will probably have gaping security holes...not an 
>NT strong suit to begin with, you end up with the worst of both worlds.

Well, according to the Interix folks (now Microsoft after they bought
them), the implementation is pretty efficient.  I have seen McIDAS-X
running on NT and it looks decent (SSEC and CIMSS folks have a number
of NT platforms).


>From address@hidden Mon Jul 10 14:25:54 2000
>Subject: Re: 20000709: FRNTDISP in MCGUI - fails 

>You mentioned the new FKey menu, so I fired it up...

>Wow.  I haven't been able to deliver the FKey menus for a couple of
>versions, iffy/flaky.  This one works great.  You spent a lot of time 
>with it.

The MCGUI is scheduled to be ADDEized ASAP (part of the holdup for the
7.7 release).  I need to do a lot of work, however, to make it simple
to use.

Bug report: (I start with your text.) 

re: RTWXTEXT stuff on vorticity.cit.cornell.edu

>Yup.  It works great from the FKey menu.  I'm am assuming that the 
>BATCH files will work, also.

It should.

>The MCGUI does not.  It fails with a tcl error message:

>               Error in tcl script
>               ERROR: Syntax Error in expression "00192/1000"
>               OK              Skip            Trace

OK, this is good information.  It sounds like a bug that was fixed
in an addendum is somehow still in your code.  I will login to
vorticity and crankup a session to see if I can sort this one out.

>Hmmm, yeah, I remember doing some hacking to get the previous version
>working....something with divide by 0 error checking...something else.
>Sorry, I don't remember what it was.  I think I removed the conditional 
>evaluation.  I'm sure you can pick this out
>easily though.  Trace is:
>               syntax error in expression "00192 / 1000"
>    while executing
>"expr $frontPltDate / 1000"
>    (procedure "frontPlot" line 48)
>    invoked from within
>"frontPlot $x $y"
>    invoked from within
>".menus.disp.mnu.obser invoke active"
>    ("uplevel" body line 1)
>    invoked from within
>"uplevel #0 [list $w invoke active]"
>    (procedure "tkMenuInvoke" line 29)
>    invoked from within
>"tkMenuInvoke .menus.disp.mnu.obser 1"
>    (command bound to event)

>                       Hope this helps...

Yes, it does help narrow down the search.

Ah... the problem was that the
date being used by frontPlot was still in YYJJJ format, not CCYYDDD (a
Y2K bug no less!).  The change was minor:

I changed:

    set frontPltDate [clock format [clock scan 0] -gmt 1 -format "%y%j"]

to:

    set frontPltDate [clock format [clock scan 0] -gmt 1 -format "%Y%j"]


in the the frontPlot procedure in the file upcguiprocs.tcl

I cranked up a McIDAS-X session as the user 'mcidas' with display back
to Boulder and ran a number of tests with your installation.  Everything
seemed to work correctly including defining of the DATALOCation for
the RTGINI dataset and display of some hi res vis imagery.

Give this one another try:

DATALOC ADD RTGINI ADDE.UCAR.EDU
DSINFO I RTGINI

<if this went OK, then>

IMGDISP RTGINI/GE1KVIS STA=KITH MAG=1 EU=IMAGE REFRESH='EG;MAP X 5 COU=ALL 
ST=NY;MAP H 6 WID=2'

You should like this!

Tom

>From address@hidden Tue Jul 11 07:05:56 2000
>Subject: Re: 20000710: ROUTE PostProcess BATCH processing and setup (cont.) 

Tom,
        in context below...
>>display/distribute through McIDAS, rather than GEMPAK? (I'm thinking of
>>the MOS/FOUS in McIDAS.)
>
>Hmm...  It might take some work.
Yeah, I'll need to put a hold on this for a while.

>re: operation in 24-bit Xwindows
>>Exactly.  Worse, the Enlightenment Xmanager consumes a LARGE color map,
>
>Right.  But with 24-bit displays, who cares.
Yup, McIDAS is great!

>>I
>>think there are only 63 colors available for GEMPAK sessions once you are
in 
>>X.
>
>Right.  You can specify how many colors are to be used with GEMPAK so that
>it will come up in environments with a lack of colors.  KDE, on the other
>hand, doesn't consume so many colors, so it is easier to run GEMPAK/GARP
>in.
Worse.  The 24 bit color map confuses the snot out of GEMPAK in general.
For example, running "ntl -g 8 -s 16 -r 8" does nothing to help, even though
there are 63 colors available and I'm only requesting 32. It appears that 
the 8 bit color is hardcoded somewhere...probably in the text stuff 
somewhere since the text uses two 8-bit chunks (attribute and character) 
to define a character in a text window (old-old)...just a guess.
   
>>Garp won't even start up, though some other programs do start. Of course,
>>the command lines work, you just can't see anything.
>
>I would tell you how to get things working if I knew.  Our GEMPAK support
>guy (Steve Chiswell) is out of the office until Wednesday.  I'll touch
>base with him when he gets back.
OK,  don't have him spend any real time on it though.  I have a real lot to 
do before semester starts and probably will not get to it for a while.
>re: Have you been working on this this morning?
>>Nope. For some reason, Fronts/Weather watch boxes are intermittent, but
>>I suspect some undefined interaction problem(s) that you may have solved
>>with the ROUTE fix. 

>I have noticed that the front reports themselves can be intermittant.
>It could be that you are just seeing their lack in the IDD.
I suspected as much. Thanks for the info.

>re: TCP wrappers
>>I opened your IP numbers.  Some stuff goes through the wrappers anyway.(I
>>don't know about McADDE, just starting to look seriously at it.)
>
>As far as I understand TCP wrappers, you would have to modify the mcserv
>and mccompress entries in /etc/inetd.conf to run the wrapper and then
>configure the wrapper layer to allow/disallow machines by IP mask.
Yup.

>re: crankup a McIDAS session and take a look at RTGINI data at UCAR
>>Uhhh, it didn't work.  
>>      DATALOC is failing I think
>>      (No data sets of type image.....)
>>      Work on it later, some support issues have come up...
>
>DATALOC can fail if the IP address for the machine can't be determined.
>If this is the case, substitute the real name of the machine for the
>alias that I provided:
>
>DATALOC ADD RTGINI motherlode.ucar.edu
>DSINFO I RTGINI
>IMGDISP RTGINI/GE1KVIS STA=KBMG ....
OK.  I see more below.

>re: running on NT using Interix and Exceed
Thanks for the comments.  I'll fire it up again after the mad rush 
of the semester startup.

>>From address@hidden Mon Jul 10 14:25:54 2000
>>Subject: Re: 20000709: FRNTDISP in MCGUI - fails 
>> re front displays: MCGUI 
>Ah... the problem was that the
>date being used by frontPlot was still in YYJJJ format, not CCYYDDD (a
>Y2K bug no less!).  The change was minor:
>
>I changed:
>
>    set frontPltDate [clock format [clock scan 0] -gmt 1 -format "%y%j"]
>
>to:
>
>    set frontPltDate [clock format [clock scan 0] -gmt 1 -format "%Y%j"]
>
>
>in the the frontPlot procedure in the file upcguiprocs.tcl
>
>I cranked up a McIDAS-X session as the user 'mcidas' with display back
>to Boulder and ran a number of tests with your installation.  Everything
>seemed to work correctly including defining of the DATALOCation for
>the RTGINI dataset and display of some hi res vis imagery.
Uhhh...yeah MCGUI works.  Now the Fkey menu for the fronts is broke:
        Surface..--->Fronts--->(F3 and F4) do nothing.  No dialog window,
no plots.  I would not bother with this since a new version is almost 
out.  I can live without since most students are not weaned from the mouse
yet. Function keys and command lines are a foreign language to most. This
was the last buggy problem I was having. Thanks for the support! On to 
upgrades and new versions!!!    

>Give this one another try:
OK
>DATALOC ADD RTGINI ADDE.UCAR.EDU
>DSINFO I RTGINI
OK
><if this went OK, then>
>
>IMGDISP RTGINI/GE1KVIS STA=KITH MAG=1 EU=IMAGE REFRESH='EG;MAP X 5 COU=ALL
ST=NY;MAP H 6 WID=2'
Huhhh? A map...
>You should like this!
Ahhhh. OK, ha ha. 'Gotta be careful about the VIS stuff.  I CAN'T see 
anything early in the morning!  Had me confused for a bit, except the screen
looked a little dirty...nope.  It's a faint image...it's still night.
Thanks! I'll look later...1K resolution and cool graphs. Enough to confirm
correct operation!
        I spent most of the day on support issues yesterday, so not much 
progress, 'cept setting up McIDAS in csh and testing. All is well.
                                Thanks guy!
                                                jdm     


James D. Marco, address@hidden, address@hidden
Programmer/Analyst, System/Network Administration, 
Computer Support, Et Al. 
Office:         1020 Bradfield Hall, Cornell University 
Home:           302 Mary Lane, Varna      (607)273-9132
Computer Lab:   1125 Bradfield            (607)255-5589