20051122: McIDAS ADDE access to NEXRCOMP imagery

>From: "Happel, Shelly" <address@hidden>
>Organization: USF
>Keywords: 200511221843.jAMIhP7s009090 IDD FNEXRAD notifyme ADDE

Hi Shelly,

>Tee hee - I've attached all of my pqact entries...

OK.

>Hmmm, where to start..

>Looks like the pqact.gempak_nexrad is running - not the
>pqact.conf_nnexrad. This pqact.gempak_nexrad looks sparse - like it
>doesn't do any decoding (which the pqact_nnexrad obviously does).

OK.

>I did do the ADDE host thing and you were right - they were pointing at
>the old IP address, however our dataloc list shows atm.geo.nsf.gov as
>the ADDE server.

The ADDE server for GINIEAST and GINICOMP.  Any others?

>Doing the dsserve.k GINIEAST - showed nada - nothing...I mean the table
>was there - but nothing filled it.

Yup.  The ADDE dataset was never setup on metlab since you are not
ingesting the feed (NIMAGE) that contains these images.  You were
always setup to access the images from a remote ADDE server (like
atm.geo.nsf.gov).

>I'm heading home now and probably won't get to this again until after
>the holiday, but again, Tom - thanks for helping me and looking at this.
>I value your time & energy spent keeping this USF ship afloat!

I logged onto metlab and took a quick look.  Here are some observations:

- you are not ingesting the NIMAGE data so you are not receiving the
  products needed for the GINIEAST, GINIWEST, GINICOMP, or RTGINI
  datasets

- you were pointing at metlab for NEXRCOMP data, but you were not
  processing the FNEXRAD images.

  I edited ~ldm/etc/pqact.conf_nnexrad and commented out the
  entry that files the NEXRAD Level III products (this is
  already being done in the pqact.gempak_nexrad file)

- like you said, you were not running a pqact to proces the actions
  in ~ldm/etc/pqact.conf_nnexrad.

  I added an exec line in your ~ldm/etc/ldmd.conf file that runs
  a separate invocation for pqact for FNEXRAD data specifying
  the use of ~ldm/etc/pqact.conf_nnexrad.  FNEXRAD composite images
  are now being processed and are accessible in the 'mcidas'
  account:

<as 'mcidas'>
cd ~/workdata
dataloc.k LIST NEXRCOMP

Group Name                    Server IP Address
--------------------         ----------------------------------------
NEXRCOMP                     METLAB.CAS.USF.EDU

<LOCAL-DATA> indicates that data will be accessed from the local data 
directory.DATALOC -- done

The images are now available:

imglist.k NEXRCOMP/1KN0R-NAT
Image file directory listing for:NEXRCOMP/1KN0R-NAT
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   5  RADAR         22 NOV 05326  23:12:00     TWX    27
imglist.k: done

imglist.k NEXRCOMP/1KN0R-FLT
Image file directory listing for:NEXRCOMP/1KN0R-FLT
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   3  RADAR         22 NOV 05326  23:17:00     TRI    1
imglist.k: done

imglist.k NEXRCOMP/6KN0R-NAT
Image file directory listing for:NEXRCOMP/6KN0R-NAT
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   3  RADAR         22 NOV 05326  23:19:00     TWX    1
imglist.k: done

imglist.k NEXRCOMP/10KRCM-NAT
Image file directory listing for:NEXRCOMP/10KRCM-NAT
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   1  RADAR         22 NOV 05326  22:50:00     TWX    1
imglist.k: done

imglist.k NEXRCOMP/2KN1P-NAT
Image file directory listing for:NEXRCOMP/2KN1P-NAT
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   3  RADAR         22 NOV 05326  23:15:00     TWX    30
imglist.k: done

 imglist.k NEXRCOMP/4KNTP-NAT
Image file directory listing for:NEXRCOMP/4KNTP-NAT
 Pos Satellite/         Date       Time      Center   Band(s)
     sensor                                 Lat  Lon
 --- -------------  ------------  --------  ---- ---- ------------
   3  RADAR         22 NOV 05326  23:15:00     TWX    31
imglist.k: done

Now, the question is if the processes being run out of your web
server cgi-bin script are using the setup from the 'mcidas' or
some other account.  If they are using the 'mcidas' account, then
displays of NEXRCOMP composite radar images should now be working.

About the GINI satellite images.  I noticed that you had
a client routing table entry for the RTGINI dataset, and the machine
being pointed to was pscwx.plymouth.edu.  If your web server is
plotting images out of this dataset, then it is now wonder that
the displays were not working -- pscwx's ADDE server has been down
for several months now (but it is being reserructed).  I changed
the pointing for RTGINI to adde.ucar.edu:

<as 'mcidas'>
cd ~/workdata
dataloc.k ADD RTGINI ADDE.UCAR.EDU

So, if your web server cgi-bin scripts were using RTGINI things should
be working now.  (I suspect that this governed the displays through
your web site's Interactive satellite page.)

I note that the regional satellite displays still are not working.  It
is likely that the web server is using configurations as a user other
than 'mcidas'.  If this is the case, it could be that user is using
McIDAS client routing table in addition to (and superceding) 'mcidas'
(~mcidas/data/ADDESITE.TXT).  The file to look for is named
MCTABLE.TXT, and it will be located in the directory indicated by the
MCTABLE_READ envrionment variable in scope for that user.  I suspect
that user might be pointing to pscwx.plymouth.edu for GINIEAST
images, and the ADDE server on pscwx.plymouth.edu is down.

A couple of comments about the USF website:

1) your page:

   http://www.weathercenter.usf.edu/sridhara/index.php

   Has a link for "Real Time Lightning Display".  Display
   of NLDN lightning data outside of one's institution is
   expressly prohibited.  Under _no_ circumstances can
   NLDN lightning data be displayed on a web page that is
   not limited to one's own institution.  If the USF
   lightning display page is not protected from outside
   access you MUST remove the link _now_!  Making lightning
   displays available through a web interface like you have
   could result in the loss of NLDN data for the entire
   Unidata community.  This is a VERY serious issue, so
   please take corrective actions ASAP.  Thanks!  (Sorry
   to be a hard ass, but this is incredibly important!!)
  
2) the same page references "Meteograms".  The proper term
   is Meteorogram.


>Happy Thanksgiving xoxo

You too (although you might not read this until after
the holiday ;-).

Cheers,

Tom
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publicly available
through the web.  If you do not want to have your interactions made
available in this way, you must let us know in each email you send to us.