[Datastream #IZJ-689237]: Additional Datafeeds

Hi Jeff,

re:
> How 'bout you just login, so that we can speed it up by not depending on me 
> :-)

Sounds good.

re:
> I've looked at the permissions some time back, assuming that was the problem,
> but didn't find anything amiss.

The directory permissions look OK.

> From what I can deduce, the actual data directory is /var/data/ldm/data,
> but there's something weird there.  Going through ~ldm/data gets me something
> different than /var/data/ldm/data, even though it appears that ~ldm/data is a
> link to /var/data/ldm/data...  I assume that I'm just missing something here.

The "standard" way that one links ~ldm/data to a different file system is:

~ldm/data -> /var/data/ldm

Your link is:

~ldm/data -> /var/data/ldm/data

No biggie.  This will not cause any problems; it is just a but unusual.

> I went in and split the RUC logging.  There were 3 different dcgrib instances
> writing to the same log file, so I split them so that I could narrow down 
> which
> one was having the writing problems.

OK.

> I also restarted ldm this morning with the new pqact.gempak setup.

Good, but I have a question:

- in the LDM pattern-action files you are pointing to the GEMPAK 5.10.4
  GEMPAK distribution that has been unpacked in 'ldm's HOME directory.

  Why did you create two GEMPAK "installations"?  One is presumably in
  /home/gempak, and the other is under /home/ldm.

Comment:

- it could be the case that one of the reasons that decoding is not working
  from some grids is that you are using an old GEMPAK release.

  I thought that you had perhaps downloaded the GEMPAK 5.11.1 release (because
  I see a ~ldm/GEMPAK5.11.1 directory), but I found that this is not the case --
  the contents of ~ldm/GEMPAK5.11.1 is a soft link that basically goes nowhere:

  [ldm@whistler ~/GEMPAK5.11.1]$ ls -alt
  total 8
  drwxrwxr-x 13 ldm mcdata 4096 Oct 15 16:00 ..
  drwxrwxr-x  2 ldm mcdata 4096 Jun  5 19:58 .
  lrwxrwxrwx  1 ldm mcdata   12 Jun  5 19:58 GEMPAK5.10.4 -> GEMPAK5.10.4

> Thanks again for all the help.  Please, just let me know what all you find
> wrong/questionable.  I want to learn as much as possible about this whole 
> thing.

I think that it would be a very good idea to try and standardize your GEMPAK
installation and use.  This means that:

- you need to install the latest GEMPAK release in the /home/gempak directory
  (current release is 5.11.1; a 5.11.4 release is being prepared by our new
  GEMPAK support person)

- get rid of a separate GEMPAK "installation" under ~ldm

- recreate the pqact pattern action files for GEMPAK using the 5.11.1
  release script

- change the read/write permissions on /home/gempak/NAWIPS so that 'ldm'
  can read tables it needs from subdirectories

The cleanup may cause a little pain right now, but it will make life easier
for you (and your successor) going into the future.

I will continue poking around to see if there is anything else that can/should
be changed to make your installation more standard.

Also, when the "smoke has cleared" WRT GEMPAK, we should take a look at the
McIDAS installation and configuration.


Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: IZJ-689237
Department: Support Datastream
Priority: Normal
Status: Closed