[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20000709: ROUTE PostProcess BATCH processing and setup (cont.)
- Subject: 20000709: ROUTE PostProcess BATCH processing and setup (cont.)
- Date: Sun, 09 Jul 2000 10:20:17 -0600
>From: "James D. Marco" <address@hidden>
>Organization: Cornell
>Keywords: 200007062021.e66KLJT26042 McIDAS-X ROUTE PP BATCH ADDE
Jdm,
> Quick update:
> All is well with the TOPO composites (a few checks over
> the weekend confirms this.)
Excellent.
> Game plan (per your recomendations):
> o Convert McIDAS and LDM to csh
Well, my online instructions use CSH examples, but there is nothing that
really demands CSH. In fact, if you are more partial to something else
like sh or ksh, I would use it. The reason? C shell users have to put
an extra bit of code in their .cshrc file that checks for MCPATH being
set. If it is set, it does not get reset when .cshrc is sourced. This
happens when scripts with McIDAS commands run.
The section of code I am referring to is:
if ( ! ${?MCPATH} ) then
setenv MCDATA /home/mcidas/workdata
setenv MCPATH ${MCDATA}:/home/mcidas/data:/home/mcidas/help
setenv MCGUI /home/mcidas/bin
setenv MCTABLE_READ "${MCDATA}/MCTABLE.TXT;/home/mcidas/data/ADDESITE.TXT"
setenv MCTABLE_WRITE "/home/mcidas/data/ADDESITE.TXT"
setenv XCD_disp_file $MCDATA/DECOSTAT.DAT
endif
> o Rebuild McPATH & McDATA dirs
OK, this should not take much:
o move ~mcidas/data/LWPATH.NAM to ~mcidas/workdata
o move all other files in ~mcidas/data that should be in ~mcidas/workdata
o remove all files from /var/data/mcidas that shouldn't be there
> o Complete user account skeleton configurations
> o Rebuild LDM feeds on 2 other machines:
> GEMPAK display server
> MM5 Modeling (query: Can I put the model
> outputs back into LDM for multiple local
> displays?)
I guess that I don't understand this question.
> Problem: McIDAS and GEMPAK require different
> color mapping configuration from the X manager.
> (Can this be bypassed somehow? Currently, I am
> using RH-Enlightenment for McIDAS and the old
> FVWM for GEMPAK. This requires users to switch the
> managers manually and they are NOT interoperable...
> a problem for all but computer geeks. )
If all machines are Linux, then both can run from KDE. This is how we ran
at the AMS show. One of the few drawbacks with GEMPAK is that it can't
run in 24-bit graphics mode. McIDAS can, and its functionality gets
better in 7.7 (some of the bugs with running in 24-bit mode were squashed).
> also:
> o Rebuild Front and Weather watch ingestion
Let's visit this one. I took a quick look at your setup this morning
(while slurping coffee at home) and noted that:
o the mcadde stuff seems to be setup OK
o the RTWXTEXT dataset looks OK for fronts
Have you been working on this this morning?
Anyway, I noticed that the remote ADDE server stuff was not going through
TCP wrappers, so I pointed my machine at it and ran several tests
successfully:
DATALOC ADD RTIMAGES VORTICITY.CIT.CORNELL.EDU
DATALOC ADD RTPTSRC VORTICITY.CIT.CORNELL.EDU
DATALOC ADD RTWXTEXT VORTICITY.CIT.CORNELL.EDU
I then (I ran displays from Fkey menu since it was ADDEized for 7.60; the
output reflects me running from the menu):
EG 11;SF 11;IMGDISP RTIMAGES/GEW-IR 11 LATLON=32 100 MAG=1 EU=IMAGE SF=YES
REFRESH='MAP H VIRT=9004;BAR ORI=VER SU=IRTEMP'
Erased graphic frame(s) 11-11
Beginning Image Data transfer, bytes= 308208
IMGDISP: loaded frame 11
MAP H VIRT=9004;BAR ORI=VER SU=IRTEMP
IMGDISP: done
EU: Restoring IMAGE.ET to frame(s)= 11
EU: Done
MAP: completed frame 11
Done
SF 11;SFCPLOT T OLAY FRAME GRIDF=132 INT=00:30 GRA=11 OUT=PLO BLANK=NO SF=YES
SFCPLOT - Done
SF 11;FRNTDISP OLAY TIME=FRAME GRIDF=132 INT=00:30 GRA=11 OUT=PLO BLANK=NO
SF=YES
FRNTDISP - Begin
FRNTDISP - Done
So, I can get fronts displayed using FRNTDISP pointing at your machine,
which means that your RTWXTEXT stuff is OK (at least for fronts).
> o Set up McADDE on McIDAS display servers
OK. I assume you understand that ADDE allows you to not have to share
the data disk with NFS, at least for McIDAS. The other good thing about
it is that it is actually faster reading products throught ADDE than
directly from an NFS mounted disk (try some tests to prove this to
yourself). The really cool thing is the ability to display data from
other ADDE servers. Try the following:
<crank up a McIDAS-X session as 'mcidas'>
DATALOC ADD RTGINI ADDE.UCAR.EDU
DSINFO I RTGINI
IMGDISP RTGINI/GE1KVIS STA=KBGM EU=IMAGE REFRESH='EG;MAP X 5 COU=ALL ST=NY;MAP
H WID=2'
Pretty cool, huh!?
> o Rebuild the old LDM/McIDAS machine to act as backup
> (and provide static display services.) RH6.0->RH6.2
> o Set up static displays for the new CMISS data
> (query: I saw a note for the stretch tables for
> these somwhere. Where can I get them?)
There are no stretch tables for these (yet). I guess I should work on
them so that data BARs will reflect the physical parameter being displayed.
> o Set up NORTMAPPER composits for CMISS data
>
>I may have a few more questions later in the week. Feel free to poke
>around and comment.
OK, like I have done this morning.
>(Seems like I always get to do things backwards: make
>it work...THEN make it work right.)
I wish the McIDAS installation/configuration was a lot less complicated.
It seems to be a rare site that configures it as per my recommendations
the first time around.
>I value your comments highly. The next
>iteration of major reconfiguration stuff will no doubt be McIDAS7.7. I
>hope to be on solid ground for that...Still scheduled for the end of the
>month? I can do some BETA testing if needed.)
I am certainly shooting for the end of July/beginning of August, but I
have run into a number of issues on one or more supported platforms that
I have to take care of one-by-one. And then, there is the datastream
change which I _really_ want to take care of at the end of the month
(so we can start providing more data).
> Side issues:
> GEMPAK updates and installation on a second server
> McIDAS/Exceed GUI displays to extend analysis
> capability from Map Room/MAD lab to the general
> computer labs (Windows NT)
Please let me know about the problems you run into displaying the McIDAS
GUI (either GUI or MCGUI) under NT/Exceed. I am suspicious that the
problem may be one of Exceed versionitis. The reason I say that is that
there is a version of McIDAS-X that runs on NT using Interix and Exceed.
I havn't been supporting this "port" since:
o both Interix and Exceed cost
o I have not had the time to build Unidata McIDAS-X on NT
o I am looking to upgrade to Windows 2000
> Thanks again!
You are welcome. Glad to see that things are working again.
Tom