20001012: McIDAS-X 7.7 build/install/configure (cont.)

>From: address@hidden
>Organization:  UVa
>Keywords:  200010111541.e9BFfL419853 McIDAS-X 7.70 configure Linux Xwidows

Jennie,

>First, thanks very much.  I think this method for establishing what
>dataset available on a server is really nice.

It was a long time coming.  I'm glad to finally see it.  I did run into
some things that I will have to grill the SSEC guys about when I
am there next week, however.

>I started a mcidas session here, and I have been able to run things,
>but, I am a little concerned about whether this system will really
>allow me to do the same work I do in the office (eg., build and save
>images with overlays, etc.).  The reason is that I just noticed that I
>am getting a color limitation (a mcimage warning on startup that the
>number of graphics colors plus image colors cannot be more than 62).  I
>am not savvy enough to know if this some kind of physical limitation of
>the Dell (memory?), or if its a result of a software configuration (I
>am presently running the Gnome windowmanager with a Desktop called
>enlightenment (Tony and Mark Lilly picked this as the default this
>summer).

This _is_ due to a software configuration.  Right now you are running
in 8-bit display mode, so you colors are limited.  Gnome takes up a lot
of colors, so you will be severely limited until you change your setup
to 24-bit mode.

>I know even on my desktop windowmanager on aerial and
>windfall, I use settings that "allow most colors for applications", in
>other words, the desktop is a pretty dull gray-scale for all the icons,
>terminals, etc.  I do this to reserve the color-table for intensive
>applications like mcidas and matlab (I always run netscape with a
>shared color table using the -install parameter).

>So, any idea what is
>causing the small number of allowed colors available to mcidas on this
>system?  (Sorry, this is probably getting pretty far from the real
>support domain, but...if you know the anwser, then...?)

Running in 8-bit mode instead of 24-bit mode.  I run in 24-bit mode here
at home, and I love it.  I have colors coming out of the wazoo.  I run
Netscape, McIDAS, and whatever else I want with no flashing problems
at all.  I must warn you that McIDAS will spit out the following warning
when you run in greater than 24-bit mode:

Using slow processing for Z-32 images

Pay no attention to this.  Your machine is a modern one, so you will never
see any effects of this (i.e., things will be fast).

>I really hope I can alter settings to improve this, otherwise I will
>have to make images on windfall anyway, and pull them over to the Dell
>to place them into my presentation (which will be made from the Dell).

Not to worry.

>I am getting pretty tired and long winded.

Since when have your emails been short? :-)

>Thanks again.  I hope this was at least useful for you in some way
>(either as a test case for your work on 7.7, or at least as a nice
>example to refer to during your upcoming McIDAS workshop).

Yes, it was.

OK, so how do you change the depth of your display?  You will have to
do this as root.  The steps are basically:

o logoff of whatever session you are running
o hit CTRL-ALT-F1 to go into one of the text terminals that is there
o login as root
o stop the window manager:

  init 3

o run Xconfigurator or XF86Setup (both in /usr/X11R6/bin)

o choose the display resolution (I use 1024x1280 but you may have to
  run in 1024x768 on your laptop; it depends on your LCD) and depth
  (again, I use 24-bit because I have 8 MB of video ram on my video
  card)

Either one of these programs will run you through a test to make sure
that the chosen display resolution and color depth will work.  After
you get to the point of it working, you will be back at the Linux
command prompt.  You can restart the windowing system with:

init 5

Then login and start mucking with McIDAS again.  In 24-bit mode you
should never run out of colors or be limited in your McIDAS display.
I routinely run with 128 colors for images, but I have pushed it up
over 200 just for grins.  Since I can't see any real difference after
about 64 colors, it doesn't much matter what I select.  Also, I always
run with 16 graphic colors, but this can be increased.  Since a number
of the settings I send out with Unidata McIDAS-X tacidly assume that
there are 16 graphic levels, I would recommend sticking with this
(these settings, of course, are in ~/.mcidasrc).

If you have troubles setting your color levels (you shouldn't with a Dell)
any Linux geek on campus can straighten you out in under a minute.

Tom

From address@hidden Wed Oct 11 20:56:55 2000
        by unidata.ucar.edu (UCAR/Unidata) with SMTP id e9C2ur411496;
        Wed, 11 Oct 2000 20:56:55 -0600 (MDT)
Message-Id: <address@hidden>
Organization: UCAR/Unidata
To: address@hidden
cc: address@hidden
Subject: 20001011: McIDAS-X 7.7 build/install/configure (cont.) 
In-reply-to: Your message of "Wed, 11 Oct 2000 17:44:46 EDT."
Date: Wed, 11 Oct 2000 20:56:53 -0600
From: Unidata Support <address@hidden>

>From: address@hidden
>Organization:  UVa
>Keywords:  200010111541.e9BFfL419853 McIDAS-X 7.70 configure ADDE

Jennie,

re: HUP signal tells inetd to reread inetd.conf

>Okay, thanks for the clarification. 

re: DSSERVEs for "standard" datasets were probably setup by hand

>Okay.

>Tom, thanks a bunch.  I will try to access this later from home and
>see if I can get to Topse archived info.  Hey, just so you
>know, the partition these files are on /q4 is real, but the
>AREA files (GRID files, etc) are links to data sitting on a remotely
>mounted disk /hsm/jlm8h.

OK.

>This is a hierarchical storage media managed by ITC (UVA Computer Center),
>we get a lot of space, but if the files are not active, there may
>be a long wait for the first reference (after that, it is pretty quick
>since the files are moved back onto the drive from the storage media...
>well, thats my understanding of it anyway)....Hope this hasn't already
>confused you.
> 
>lrwxrwxrwx   1 ldma     mcidas        53 Mar  7  2000 AREA6540 -> /hsm/jlm8h/t
> opseA/images/goes8wv/200002292115.goes8wv

If the files are really specified like:

/hsm/jlm8h/topseA/images/goes8wv/200002292115.goes8wv

then this can be used directly to setup the datasets.  In fact, it is
better than referring to the link!  You may want to consider dropping
the links you setup in favor of the real file pathnames.  See below.

After setting up TOPSEA, I did a quick IMGLIST:

IMGLIST TOPSEA/GE-AW
Image file directory listing for:TOPSEA/GE-AW
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
 136  G-8 IMG       29 FEB 00060  18:00:00    23   71 3
IMGLIST: done

So, you can see that it worked.

I took the information you had put into files like ADDTOPSEA.BAT/TOPSEA.NAM,
etc. and created a McIDAS BATCH file to setup all of your TOPSE datasets
in one fell swoop.   The file is /home/mcadde/TOPSEADDE.BAT.  The DSSERVE
commands in it were "activated" by:

batch.k \"TOPSEADDE.BAT

I also took the same information and created a second BATCH file,
TOPSEADDE2.BAT, that used the direct file names like:

/hsm/jlm8h/topseA/images/goes8wv/200002292115.goes8wv

Both of these BATCH files setup the same set of datasets: TOPSEA, TOPSEB,
TOPSEC, and TOPSED.

After running:

batch.k \"TOPSEADDE.BAT

the datasets definitions were created, but I was unable to see files
either through an IMGLIST or through a simple 'ls' in the Unix
session.  My guess is that the images were needing to be moved back to
an active partition from the mass storage system.  There must be a way
of forcing this from the Unix command line so that ADDE access to the
data will be quick.

I think that if you look at the contents of TOPSEADDE.BAT and
TOPSEADDE2.BAT, you will get the idea of how the 7.7 version of DSSERVE
can be run, and how it does not need to use REDIRECTions or MCPATH (big
win).

Also, if you look at /home/mcadde/data/LSSERVE.BAT, you will see how I
setup your realtime datasets.  I was attempting to totally update the
DSSERVE commands to use the DIRFILE= keyword syntax, but I ran into
problems coming up with regular expressions that would match thins
like:

DSSERVE ADD RTPTSRC/SFCHOURLY MD 1 10 RT=YES "Realtime surface point sourc data

If the MD files ranged from 0 to 9, the regular expression would be
easy (MDXX000*), but it is more like: (MDXX000*|MDXX0010). Images in
AREA files are saved in this way, so they are easy.  Also, the way you
were saving data for TOPSE was also nice in that it made setting up
regular expression easy.

It seems as though the code SSEC added does not understand the
(MDXX000*|MDXX0010) construct (or I am screwed up by how it should
work).  I may keep playing with this on windfall to see if I can come
up with something.  I _really_ would like it if the files could be
specified without having to use _any_ REDIRECTions or MCPATH.

>later,

Yup, it is later.  I had to run out and pickup a keg (for me) and run
to the Liquor Mart to snarf up stuff for Sally's retirement party
tomorrow.

Tom