20011211: setup of ldm-mcidas, LDM, XCD, and McIDAS at COFC

>From: "James R. Frysinger" <address@hidden>
>Organization: College of Charleston
>Keywords: 200111061842.fA6Igt112242 LDM binary install

Jim,

>Logged on remotely as frysingj and saw you were on as ldm; tried 'talk' 
>to no avail.

At the time you saw this, I was probably in the process of logging off
from home and heading into work (for a meeting, groan).

>I saw (via 'who') that apparently two of my remote connections to ldm 
>on Dec 06 had failed to close out; killed them manually. I wonder if 
>this might have led to the strange behavior, though I doubt it would.

This would not have been a problem.

>From address@hidden Tue Dec 11 10:46:52 2001

>I see you folks are hard at it, straightening out my mess.

Let's just say that I was putting the icing on the cake :-)  All-in-all
things weren't so bad, but some tweaking was in order.  I will detail
what I did, and why I did it below.

>I'm at home 
>today grading papers and otherwise bored to death. (G.W. Bush has the 
>downtown are tied up with his visit to The Citadel.)

Better you than me :-)

>If'n you need to call me to do some root type things that can be done 
>remotely, or whatever, I'm at .....

OK, thanks.  I think that everything is moving along nicely now.  The
LDM is merrily grabbing data and the ldm-mcidas and XCD decoders are
decoding like crazy.  Your disk is getting populated with data, and
I removed a bunch of data files that were the results of the default
pqact.conf FILE action that comes with a new LDM install.  I have since
commented out that action and freed up on the order of 8 GB of disk
space that was being used by that data.

OK, so here is what I have done:

-- as user 'ldm' --

1) corrected a typo in the 'xcd_run DDS' action in pqact.conf.  The
   action previously read:

DDPLUS|IDS      ^."     PIPE
        decoders/xcd_run DDS
HRS     ^.*     PIPE
        decoders/xcd_run HRS

   it should read (and now does):

DDPLUS|IDS      ^.*     PIPE
        decoders/xcd_run DDS
HRS     ^.*     PIPE
        decoders/xcd_run HRS

   This typo was preventing POINT source data decoding by XCD.

2) modified all ~ldm/etc/pqact.conf entries to specify directory/decoder
   as the decoder to run.  As I mentioned in a previous email, this
   is important for folks (like you) who will be running ldmfail from
   cron.

3) modified ~ldm/etc/ldmd.conf to:

   a) include the full pathname for xcd_run in its exec line:

exec    "/export/home/ldm/decoders/xcd_run MONITOR"

      this was needed for the same reason as 2)

   b) added request of FSL2 data from atm.geo.nsf.gov.  The FSL2
      data is the FSL wind profiler data.  This is not as useful
      for East Coast folks such as yourself as it is for sites
      in the middle of the country, but I figured you might want
      to look at the data anyway.

   c) modified the request lines for UNIDATA so as to make switching
      the feed host easier:

request UNIDATA ".*"
        pluto.met.fsu.edu
#       cirp.met.utah.edu

      to change the feed from pluto to cirp, you only have to comment
      out one line and comment the other:

request UNIDATA ".*"
#       pluto.met.fsu.edu
        cirp.met.utah.edu

   d) added a request for the NMC3 feed (aka FNEXRAD) from atm.geo.nsf.gov.
      This feed contains NEXRAD floater sites and several regional
      composite base level reflectivities in grib format.  This
      product is especially useful in GEMPAK and will be in McIDAS as
      soon as I figure out how to decoded it with the XCD grib decoder.
      I will add the pqact.conf actions needed to deal with this data
      later today.  The request will need to get updated to FNEXRAD
      after atm.geo.nsf.gov's LDM gets upgraded to 5.1.4.

   e) I setup the request line for NLDN lightning data from SUNY Albany.
      You need to send an email to Dr. David Knight <address@hidden>
      (with CC to address@hidden) requesting that they allow
      weather.cofc.edu to request an NLDN feed.  Your LDM is currently
      requesting the data from SUNYA, but it is being denied access
      by their LDM server, so you need to send David a request for
      a feed.

   f) I removed allow lines for NLDN data for pluto.met.fsu.edu and
      cirp.met.utah.edu.  NLDN data can NOT be relayed by Unidata IDD
      sites.  All NLDN feeds are point-to-point from SUNY Albany to 
      the university desiring the data.  Also (I noted this before),
      the NLDN data and/or depcitions of that data (GIFs (tm), JPEG,
      etc.) may _never_ be posted on a web page that can be viewed
      from any site not on the individual university's campus.  Breaking
      this restriction will result in immediate, and permanent loss
      of the data.

   g) allow ANY from your upstream feed hosts

   h) modified ~ldm/etc ldmd.pluto.met.fsu.edu and ldmd.cirp.met.utah.edu
      to:

      o startup '/export/home/ldm/decoders/xcd_run MONITOR'

      o request UNIDATA from the appropriate host

      o request FSL2|NMC3 from atm.geo.nsf.gov

      o only request NLDN from striker.atmos.albany.edu

      o allow ANY for your upstream feed sites
      
      These mods should make things work correctly when ldmfail changes
      the host you are feeding UNIDATA from.

4) edited ~ldm/decoders/mcscour.sh to keep 3 days of McIDAS POINT data
   onlne.  This was set to 2 days.

5) stopped and restarted the LDM numerous times to test out all of the
   changes made

6) added a cron entry that rotates the ADDE server log file, SERVER
   (SERVER.2 -> SERVER.3; SERVER.1 -> SERVER.2; SERVER -> SERVER.1;
   and a new SERVER gets created).  This log file is rotated once a week.

7) annotated 'ldm's crontab entries (so it is easy to read what the
   entries are all about (crontab -l)

<as user 'mcidas'>

1) modified ~mcidas/.mcenv to set the environment variable ADDE_LOGGING.
   Added a REDIRECTion for SERVER* to /export/home/mcdata/ldm/logs.
   SERVER will be the file in which ADDE requests are logged.  SERVER
   will be "rotated" by an 'ldm' cron entry (see 6) above).  Once
   the logging gets rolling, you can use the McIDAS ADDEINFO command
   to review ADDE use.  Use the HELP ADDEINFO sequence from a McIDAS
   session running as 'mcidas' for information on what you can list
   out with this command.

2) edited .cshrc and moved things around a bit (no major changes).  Added
   an alias for 'lt' which is a long, time oriented list whose output
   is piped into 'more'.  Use:

   lt /export/home/mcdata

3) turned on generation of GOES East/West composite imagery:

   cd ~mcidas/workdata
   route.k REL C

   Turned on generation of GOES and topography composite imagery:

   route.k REL N

   The composite products are being created.  The are accessible
   as are the other images ingested from the Unidata-Wisconsin feed
   (LDM feed type MCIDAS which is part of the UNIDATA feed) in the
   ADDE dataset RTIMAGES:

imglist.k RTIMAGES/GEW-IR.ALL
Image file directory listing for:RTIMAGES/GEW-IR
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   1  G-8 IMG       11 DEC 01345  11:15:00    26  100 4
   2  G-8 IMG       11 DEC 01345  12:15:00    26  100 4
   3  G-8 IMG       11 DEC 01345  13:15:00    26  100 4
   4  G-8 IMG       11 DEC 01345  14:15:00    26  100 4
   5  G-8 IMG       11 DEC 01345  15:15:00    26  100 4
   6  G-8 IMG       11 DEC 01345  16:15:00    26  100 4
   7  G-8 IMG       11 DEC 01345  17:15:00    26  100 4
   8  G-10 IMG      11 DEC 01345  18:00:00    26  100 4
   9  G-10 IMG      11 DEC 01345  19:00:00    26  100 4
  10  G-8 IMG       11 DEC 01345  10:15:00    26  100 4
imglist.k: done

Finally, I logged on as you and snooped in the .cshrc file looking for
typos, etc.

1) I moved the definition of path down below the block that defines McIDAS
   stuff (not a biggie; just part of me being anal).

2) set DISPLAY back to my machine at Unidata (after setting my xhost to
   allow the connection), and then started a McIDAS session:

   mcidas config

   Selected auto start of MCGUI and save settings to defaults file.  The
   latter setting caused ~frysingj/.mcidasrc to be created.  I also set
   up defaults for starting a session with 600x800 windows instead of
   the default 480x640.  I find that the larger display windows are much
   more pleasing.

   Exercised the MCGUI and found that things appear to be working reasonably
   well.  I plotted:

   meteorogram
   latest GOES-East VIS image
   surface plot of temperatures over South Carolina
   overlaid surface T plot with contours of surface pressure
   overlaid surface T and pressure map with fronts from the same time

   All of these displays were created using data that weather had received
   over the IDD and decoded with ldm-mcidas and McIDAS-XCD decoders.

So, I can verify that the following are working correctly:

o LDM/IDD
o ldm-mcidas decoders
o McIDAS-XCD decoders
o ADDE remote server

While it may seem like a I did a lot, the total amount of time needed
to make the mods was on the order of a half hour.  The thing that takes
the most time when doing something like this is documenting what was done
so that the end user (you) will have a record of what was changed and
why.

OK, so back to one of the problems you were having yesterday.  When
you tried to start a McIDAS session, you got a warning about not being
able to allocate colors.  This is caused by your system running X in
8-bit mode AND there already being applications running (maybe even
CDE itself) that are using most of the available colors.  If you are
not running Netscape or other applications and you still get this
problem, you will need to modify your CDE environment to use less
colors.

When you get a chance, could you logon from work and try running McIDAS
as yourself?  You can now bring up McIDAS with the MCGUI automatically
by simply running:

mcidas

This was made possible by the 'mcidas config' settings referenced to
above.

Ciao...

Tom