20030820: McIDAS 2003 LSSERVE Q. (cont.)

>From: "Thomas L. Mote" <address@hidden>
>Organization: UGa
>Keywords: 200308071535.h77FZeLd002958 McIDAS LSSERVE.BAT UGAGINI.CFG

Hi Tom,

>Thanks much. The IP number for cacimbo did change in May about the
>same time we updated the OS.

OK, everything makes sense now.  BTW, if you anticipate that the
IP for cacimbo will change routinely, you could create a cron
entry in the 'mcidas' account that does the script equivalent
of 'DATALOC HOST' every month/week/day/hour, etc.  This would force
the set of hostname/IP address pairs to be consistent at least on
the timeframe of the cron job.  Just a thought...

>You're right about the nexrad/satellite
>holdover products. I haven't tried to figure out what needed to go...
>never the sort of thing that made it to the top of a "to-do" list.
>Thanks for taking care of it.

No worries.  Deleting dataset definitions is very easy.  All one has to
do is use his/her favorite editor and edit ~mcidas/workdata/RESOLV.SRV
and remove all of the lines for that dataset.  The slightly tricker
part is remembering to update ones LSSERVE.BAT file to comment out
the dataset definition(s) so that they will not get recreated the
next time 'mcidas' runs 'batch.k LSSERVE.BAT'.

>I tried running the redirect.k ADD command myself earlier. I don't
>know why that didn't work. I used "GRID6*" instead of "GRID6", but
>it was otherwise the same. I didn't try the others after that failed.

If you ran this from the Linux command line, you would need to escape
the '*' and '"' used in the REDIRECT:

cd ~mcidas/workdata
redirect.k ADD GRID6\* \"/data/mcidasd

The other "gotcha" is trying to do this while the LDM is running.
Here is what happens:

- the LDM starts the McIDAS XCD supervisory routine startxcd.k on
  startup by virtue of the entry:

  exec  "xcd_run MONITOR"

  in one's ~ldm/etc/ldmd.conf file.

- startxcd.k inherits McIDAS environment variable settings (specified
  in xcd_run) upon startup, AND it never exits (so new settings never
  get read.  One of the first things that is read in is the list
  of REDIRECTions found in LWPATH.NAM which, in turn, is found
  through the definition of MCPATH in xcd_run.  That set of REDIRECTions
  is then cached in memory -- never to be read again until startxcd.k
  is stopped (by an 'ldmadmin stop') and restarted (by an 'ldmadmin start').
  So, you can change the REDIRECTions over in the 'mcidas' account, and
  the changes will never get picked up by the invocation of startxcd.k
  running over in the 'ldm' account.  The last piece of this is that
  startxcd.k _may_ under certain circumstances flush the REDIRECT entries
  it has cached in memory back to disk (to the file LWPATH.NAM).  This
  means that a new REDIRECTion you enter as 'mcidas' while the LDM
  is running may be lost by LWPATH.NAM being overwritten.

>I went ahead and made the changes you mentioned on the ldm side and
>restarted. So I think we're squared away.

Excellent, thanks!  I can see all of the images in the NEXRCOMP dataset
now.

>We have received the "new" cacimbo, and I'll ask our departmental tech
>people to set it up shortly. It is also running RedHat 8 (same kernel
>version as well, I believe), so I should be able to just tar up the
>entire home directory and move it over.

Yes, -- as long as _everything_ in the 'mcidas' account is identical on
the new machine.  What wouldn't work for McIDAS is, for example, the
HOME directory being /home/mcidas on oldcacimbo and /usr/local/mcidas
on newcacimbo.  If the HOME directory changes, McIDAS _will_ need to be
rebuilt.  Give that you are putting in a new, presumably fast machine,
the rebuild won't take long.  The speed record for building Unidata
McIDAS-X/-XCD now stands at 5:37 (5 minutes and 37 seconds!; this was
accomplished on a dual Athlon 2400+ FreeBSD machine here at the UPC.
The configuration files for ADDE servers will remain the same as long
as the directories in which things are stored remain the same from the
old to new machine.

>Hopefully, there will be no
>additional configuration (other than the services, xinetd, etc.) to be
>done.

Right.

>BTW, I noticed as I was setting up systems for the fall that the linux
>binaries for gempak 5.6.k didn't work on RH8/9 (NMAP core dumped), but
>when I tried the 5.6.j binaries, they worked fine.

I was chatting with Chiz about GEMPAK binaries recently, and he was
lamenting the fact that binaries built on RedHat 7.3 were not
necessarily usable on 8/9.

>I didn't have time to
>try to build "k" from source, and it didn't seem critical for my needs.

I always like to build software packages on the machines they are going
to run on since things are likely to work better/more reliably than a
binary built on a "similar" system.

>I may send a separate message to Chiz as an FYI.

OK.

>Thanks again for all your help...

Now, I have a question:

In going through your ADDE setup for NOAAPORT GINI images, I notice
that:

- the naming convention for images is not consistent.

  Example:
  
  The GOES-East CONUS, GOES-West CONUS, Super National composites,
  images and 24 km East/West composites have names that look like:

  <band>_CCYYMMDD_HHMM.gini

  All other images follow:

  <band>_CCYYMMDD_HHMM

  (no .gini suffix)

  Are the different naming conventions going to stay?  This affects
  the file name masks in ~mcidas/workdata/UGAGINI.CFG which I
  have been adjusting to match what I see in /data/goeseast/ and
  /data/goeswest.

- for more than one dataset, the images being filed as one channel
  are actually for a different channel.  One example is the Hawaii
  Regional images which are accessible through ADDE datasets
  GINIWEST/GHR1KVIS, GINIWEST/GHR8KWV, GINIWEST/GHR8KWV,
  GINIWEST/GHR4K39, GINIWEST/GHR4KIR, and GINIWEST/GHR4K12.  When I
  load these images using McIDAS, the band number of the image changes,
  but the contents (what actually gets displayed) are all blank
  (black).  That the images are coming in on NOAAPORT OK can be seen by
  pointing McIDAS at adde.ucar.edu for the GINIWEST dataset and then
  loading the various Hawaiin Regional images.  The same comment can
  be made for the Puerto Rican Regional images.

In closing for now, I can say that the ADDE dataset definitions for
GINICOMP, GINIEAST, GINIWEST, and RTGINI (i.e., the entries in
~mcidas/workdata/RESOLV.SRV and ~mcidas/workdata/UGAGINI.CFG) are now
setup correctly.  The blank images for Hawaii and Puerto Rico (and
others?) needs to be investigated.

Tom