[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GEMPAK #VFW-525515]: A bit more about why the decoders might not be working....

within that session the GEMDAT env var should still be set to data/data so 
you'll not see it interrupt your plots.

alas, that change only caused the ldm decoders to not find the directory.

I finally found the cause of the problem: there was an entry ":bin:" in $PATH, 
set in .bashrc, which came before "/usr/local/ldm/bin",

PATH=/usr/local/ldm/decoders:/usr/local/ldm/util:/usr/local/ldm:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/ldm/bin

This was causing the ldm session to find ldmadmin and other programs in the 
relative path "bin" from ~ldm before it could source them from 
/usr/local/ldm/bin.  The testable result of this was being unable to run 
ldmadmin in any directory but ~/

I removed bin from $PATH, logged back in, and watched it for a bit and I see 
dcmetr and dcgrib2 decoding fine but they are storing files still in data/data. 
 will update you soon.

Michael

> I might have it locked.  I'm logged in as gempak on the old env...   I
> was getting a plot out for a proposal.
> 
> Ray
> 
> 
> On Thu, Dec 13, 2012 at 4:41 PM, Unidata GEMPAK Support
> <address@hidden> wrote:
> >
> > The UNIWISC feed is included with the UNIDATA feed, see the feedtype page 
> > for what's included in what:
> >
> > http://www.unidata.ucar.edu/software/ldm/ldm-current/basics/feedtypes/
> >
> > So how the LDM uses feedtypes is like this:
> >
> > The "REQUEST ANY" line will pull all feedtypes from the upstream LDM.  Each 
> > EXEC line feedtype definition will determine which products go to which 
> > pqact file, so
> >
> > EXEC    "pqact -f UNIDATA /usr/local/ldm/etc/pqact.conf"
> >
> > will send all products from feed UNIDATA into pqact.conf to match product 
> > header regular expressions for processing.
> >
> > EXEC    "pqact -f NGRID|CONDUIT|HDS /usr/local/ldm/etc/pqact.gempak"
> >
> > will send products from these three feeds into pqact.gempak for processing.
> >
> > Now there are entries in pqact.gempak for feedtypes FNEXRAD, CMC, NOGAPS, 
> > WMO and others, but because I used "-f NGRID|CONDUIT|HDS", these files will 
> > not be decoded.
> >
> > The fix is to change  -f NGRID|CONDUIT|HDS to include the relevant feed 
> > names (UNIDATA), or use "-f ANY" for pqact.gempak.  That is how the 
> > products processed by each pqact file are managed.
> >
> > As for the double data/data directory, it was my guess that it was due to 
> > the LDM appending data onto GEMDATA and that it would be solved now if 
> > GEMDATA is defined back to "data" rather than "data/data".
> >
> > I made this change to Gemenviron.profile and restarted the LDM to check, 
> > but so far I haven't seen any data written yet.  I'll keep an eye on it 
> > today and try some other things, but feel free to go in and modify the 
> > configuration to suit your needs.
> >
> >
> >
> > Michael
> >
> >> Michael,
> >>
> >> Depends on what you mean by "correct"....    Decoders are writing to
> >> $GEMDATA/surface etc.   GEMDATA is pointing to
> >> /mnt/sdb/var/data/data/gempak
> >>
> >> I can live with that.   GEMPAK runs on model data and surface data,
> >> which is what I tried and $GEMDATA in the sffile works.
> >>
> >> I noted that UNIWISC's image data is not writing the GOES images now.
> >> You pointed the REQUEST to ANY but put a -f UNIDATA   and a -f
> >> NGRID/CONDUIT/HDS in the two EXEC's that remain:
> >>
> >> EXEC  "pqact -f UNIDATA /usr/local/ldm/etc/pqact.conf"
> >> EXEC  "pqact -f NGRID|CONDUIT|HDS /usr/local/ldm/etc/pqact.gempak"
> >>
> >> Do I need to explicitly add a pqact -f UNIWISC
> >> /usr/local/ldm/etc/pqact.gempak   to get the imagery to come down?
> >>
> >> I should understand the -f, I guess.   This writes all UNIDATA
> >> products out?  I thought that was inclusive of FT1-5 streams,. which
> >> includes the imagery from UNIWISC.
> >>
> >> Ray
> >>
> >> On Thu, Dec 13, 2012 at 1:55 PM, Unidata GEMPAK Support
> >> <address@hidden> wrote:
> >> > Sure.
> >> >
> >> > Any data being written to the correct $GEMDATA now?
> >> >
> >> >
> >> >
> >> >
> >> >> Thanks, Michael.  Great job.
> >> >>
> >> >> So can I shut off rtstats in ldmd until we get a read on it?
> >> >>
> >> >> Ray
> >> >>
> >> >> On Thu, Dec 13, 2012 at 11:30 AM, Unidata GEMPAK Support
> >> >> <address@hidden> wrote:
> >> >> > Raymond,
> >> >> >
> >> >> > When I set SFFILE = $SAO/20121213_sao.gem sflist finds and reads the 
> >> >> > file.  When I set SFIFLE = $GEMDATA/surface/20121213_sao.gem I can 
> >> >> > confirm it does not get found.
> >> >> >
> >> >> > This is tied to the bash shell not having $GEMDATA defined in "env", 
> >> >> > though it does return when you type "echo $GEMDATA".  The reason for 
> >> >> > this was a forgotten export command after the variable is defined in 
> >> >> > NAWIPS/Gemenviron.profile.  I added the export and re-sourced the 
> >> >> > file and tested with sflist and it worked.  It's one of those small 
> >> >> > but invisible problems that sometime take too long to find when 
> >> >> > scanning a file for errors.
> >> >> >
> >> >> > As for the RPC timeout on rtstats, I'm going to have our LDM 
> >> >> > developer read this over since what I can find in our support 
> >> >> > archives only speaks about a server-side issue.
> >> >> >
> >> >> >
> >> >> > Michael
> >> >> >
> >> >> >> Michael,
> >> >> >>
> >> >> >> Yep, appears to be working as ruc is now writing into model.
> >> >> >>
> >> >> >> I note that you have EXEC pqact.gempak running in ldmd.conf  so all
> >> >> >> those decoders are running on the REQUEST ANY?
> >> >> >>
> >> >> >> I guess I don't need to insert decoders in pqact.conf since they are
> >> >> >> running in pqact.gempak?
> >> >> >>
> >> >> >> I can say with some certainty that I would not have had the 
> >> >> >> confidence
> >> >> >> to edit out the decoders/ and GEMTBL pointers.  I did have a guy in 
> >> >> >> my
> >> >> >> office suggest making all the calls explicit but batch editing a 
> >> >> >> bunch
> >> >> >> of decoder calls and I would have lost more sleep.
> >> >> >>
> >> >> >> I still think there is a bit of an issue in defining $GEMDATA..... it
> >> >> >> points explicitly to /mnt/sdb/var/data/gempak.   GEMPAK can't see the
> >> >> >> data as they are in /mnt/sdb/var/data/data/gempak.  I don't want to
> >> >> >> have to be changing the Gemenviron to fix $LDMDATA and $GEMDATA, no?
> >> >> >>
> >> >> >> I tried running GEMPAK and get file not found.   The GEMPAK env shows
> >> >> >> most of the nmemonics for GOES8 , NLDN, HDS, etc. pointing too far up
> >> >> >> in that directory.  /mnt/sdb/var/data/gempak  (not the double
> >> >> >> data/data tree).
> >> >> >>
> >> >> >> Any idea of why that is happening in LDM?
> >> >> >>
> >> >> >> Ray
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Wed, Dec 12, 2012 at 1:28 PM, Unidata GEMPAK Support
> >> >> >> <address@hidden> wrote:
> >> >> >> > Raymond,
> >> >> >> >
> >> >> >> > I made a few edits to ldmd.conf and the pqact files pqact.conf and 
> >> >> >> > pqact.gempak.
> >> >> >> >
> >> >> >> > I think the root of the problem was the relative path name 
> >> >> >> > "decoders/dcgrib2" in the pattern actions for decoders.  I removed 
> >> >> >> > "decoders/" from all entries, and also changed GEMTBL in these 
> >> >> >> > files to point to "/home/gempak/NAWIPS/..." rather than 
> >> >> >> > "/home/gempak/GEMAK6.7.0/...", which isn't responsible for the 
> >> >> >> > problem, but is good practice for when upgrading to a new version .
> >> >> >> >
> >> >> >> > Lastly, I changed the EXEC lines in ldmd.conf to specific the feed 
> >> >> >> > type and pqact file using the fully-qualified pathname:
> >> >> >> >
> >> >> >> > EXEC    "pqact -f UNIDATA /usr/local/ldm/etc/pqact.conf"
> >> >> >> > EXEC    "pqact -f NGRID|CONDUIT|HDS 
> >> >> >> > /usr/local/ldm/etc/pqact.gempak"
> >> >> >> >
> >> >> >> > After this, I noticed model data decoded to ~ldm/data/data/gempak 
> >> >> >> > - still the double "data" in the path.
> >> >> >> >
> >> >> >> > I redefined LDMHOME in user gempak's Gemenviron.profile and 
> >> >> >> > re-sourced the file into the gempak user's environment, then 
> >> >> >> > restarted the ldm again from the ldm account.
> >> >> >> >
> >> >> >> > I have yet to see model data written to ~ldm/data/gempak/model/ 
> >> >> >> > but I'm going to keep it running for an hour or so and come back 
> >> >> >> > to look at it later.  Feel free to check it out and make 
> >> >> >> > adjustments as needed.  I have to go to a meeting and will check 
> >> >> >> > back in this afternoon.
> >> >> >> >
> >> >> >> > Michael
> >> >> >> >
> >> >> >> >
> >> >> >> >> Michael,
> >> >> >> >>
> >> >> >> >> I'm still stuck on this write problem with the GEMPAK decoders.  I
> >> >> >> >> have checked and double-checked the env variables and they seem 
> >> >> >> >> fine
> >> >> >> >> and the permissions to write to the data/gempak/surface and
> >> >> >> >> data/gempak/log directory is 777 so anyone can write to it.
> >> >> >> >>
> >> >> >> >> Is there a way that I can invoke this decoder:
> >> >> >> >>
> >> >> >> >> WMO   ^S[AP]
> >> >> >> >> PIPE  decoders/dcmetr -v 2 -a 500 -m 72 -s sfmetar_sa.tbl
> >> >> >> >> -d data/gempak/logs/dcmetr.log
> >> >> >> >> -e GEMTBL=/home/gempak/GEMPAK6.7.0/gempak/tables
> >> >> >> >> data/gempak/surface/YYYYMMDD_sao.gem
> >> >> >> >>
> >> >> >> >> on a file rather than going through the PIPE to see specifically 
> >> >> >> >> what
> >> >> >> >> is happening here.  Can I run decoders/dcmetr on a file to check 
> >> >> >> >> this
> >> >> >> >> out?  Do you have a simple, few line test file that dcmetr should
> >> >> >> >> decode to /surface/YYYMMDD_sao.gem?
> >> >> >> >>
> >> >> >> >> Ray
> >> >> >> >>
> >> >> >> >> On Thu, Dec 6, 2012 at 1:20 PM, Unidata GEMPAK Support
> >> >> >> >> <address@hidden> wrote:
> >> >> >> >> > I'm going to suggest the sym link $OS_BIN to ~ldm/decoders be 
> >> >> >> >> > removes, and copy (as user ldm) all dc programs to the 
> >> >> >> >> > directory ~ldm/decoders/ "cp $OS_BIN/dc* ~ldm/decoders/.
> >> >> >> >> >
> >> >> >> >> > Then rehash or re-login and check with "which dcgrib2" and test 
> >> >> >> >> > your scripts again.  Might simply be a permission issue with 
> >> >> >> >> > user gempak owning the programs.
> >> >> >> >> >
> >> >> >> >> > And like you said, I'm also worried about the double 
> >> >> >> >> > ldm/data/data/ - send me back the current list of "env" from 
> >> >> >> >> > both gempak and ldm users, there's a conflict somewhere and I'm 
> >> >> >> >> > still not sure where.
> >> >> >> >> >
> >> >> >> >> > -Michael
> >> >> >> >> >
> >> >> >> >> >> Michael,
> >> >> >> >> >>
> >> >> >> >> >> If I cd to ~ldm/decoders and run a script it seems to start
> >> >> >> >> >>
> >> >> >> >> >> If I run the script as decoders/acprof,  I get errors....    
> >> >> >> >> >> See  >>>>>
> >> >> >> >> >>
> >> >> >> >> >> [ldm@awipserver decoders]$ acprof
> >> >> >> >> >> [IP -2]
> >> >> >> >> >> [IP -10] ACPROF
> >> >> >> >> >> Creating process: gplt for queue 294914
> >> >> >> >> >> [LV -3]
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> ^C out of there....
> >> >> >> >> >>
> >> >> >> >> >> [ldm@awipserver decoders]$ cd ~
> >> >> >> >> >> [ldm@awipserver ~]$ decoders/acprof
> >> >> >> >> >> [IP -2]
> >> >> >> >> >> [IP -10] ACPROF
> >> >> >> >> >> [GEMPLT -101]
> >> >> >> >> >> [ACPROF -3]
> >> >> >> >> >> Error in message send = 22
> >> >> >> >> >> itype, ichan, nwords,0,294914,3
> >> >> >> >> >> [ldm@awipserver ~]$
> >> >> >> >> >>
> >> >> >> >> >> Maybe it won't run through the symbolic link?
> >> >> >> >> >>
> >> >> >> >> >> Ray
> >> >> >> >> >> On Wed, Dec 5, 2012 at 5:13 PM, Unidata GEMPAK Support
> >> >> >> >> >> <address@hidden> wrote:
> >> >> >> >> >> > As user ldm, confirm on login that the decoders are in your 
> >> >> >> >> >> > path: "which dcgrib2" should point to ~/decoders/dcgrib2 or 
> >> >> >> >> >> > $OS_BIN/dcgrib2
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >> Michael,
> >> >> >> >> >> >>
> >> >> >> >> >> >> Ok still did not get there......  I made a symbolic link to 
> >> >> >> >> >> >> the
> >> >> >> >> >> >> directory pointed to by gempak $OS_BIN.  ldm tries to run 
> >> >> >> >> >> >> them out of
> >> >> >> >> >> >> the gempak directory.
> >> >> >> >> >> >>
> >> >> >> >> >> >> decoders -> /home/gempak/GEMPAK6.7.0/os/linux64/bin/
> >> >> >> >> >> >>
> >> >> >> >> >> >> All the dc files are permission 755  rwxr-xr-x  so ldm 
> >> >> >> >> >> >> should be able
> >> >> >> >> >> >> to run them.
> >> >> >> >> >> >>
> >> >> >> >> >> >> But if you look at the last ldmd.log  (attached) it says 
> >> >> >> >> >> >> the decoders
> >> >> >> >> >> >> don't run.   Barring moving them directly to the 
> >> >> >> >> >> >> ldm/decoders
> >> >> >> >> >> >> directory, see anything else?
> >> >> >> >> >> >>
> >> >> >> >> >> >> All the decoder calls are preceded by a "No such file or 
> >> >> >> >> >> >> directory"
> >> >> >> >> >> >> but without going into the scripts for decoders/dcgrib2 for 
> >> >> >> >> >> >> example, I
> >> >> >> >> >> >> don't know what directory it is looking for.
> >> >> >> >> >> >>
> >> >> >> >> >> >> Ray
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> On Wed, Dec 5, 2012 at 3:01 PM, Unidata GEMPAK Support
> >> >> >> >> >> >> <address@hidden> wrote:
> >> >> >> >> >> >> > $LDMHOME for the gempak user must be able to read where 
> >> >> >> >> >> >> > the ldm is filing and decoding data.  This appears to be 
> >> >> >> >> >> >> > setup correctly on your system with the only change 
> >> >> >> >> >> >> > needed the directory ~ldm/decoders.
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > However I don't see GEMDATA in 'env' for the gempak user, 
> >> >> >> >> >> >> > though from $HDS and other data environmental variables, 
> >> >> >> >> >> >> > it appears to be set.
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > -Michael
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> Ok,
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> I must have missed that instruction in the cookbook.  
> >> >> >> >> >> >> >> I'll make that fix .
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> The /usr/local/ldm/data   symbolic link then SHOULD (?) 
> >> >> >> >> >> >> >> be to
> >> >> >> >> >> >> >> /mnt/sdb/ldm/var/data  ????
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Also ldm and gempak are separate users so why should ldm 
> >> >> >> >> >> >> >> know about
> >> >> >> >> >> >> >> the gempak environment variables?  Should they be 
> >> >> >> >> >> >> >> separate or in a
> >> >> >> >> >> >> >> group?  Could it be that gempak didn't write the 
> >> >> >> >> >> >> >> decoders because it
> >> >> >> >> >> >> >> didn't have permissions in the ldm group?
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Thanks, I'll try these fixes later today and let you 
> >> >> >> >> >> >> >> know the outcome .
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Ray
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> On Wed, Dec 5, 2012 at 2:44 PM, Unidata GEMPAK Support
> >> >> >> >> >> >> >> <address@hidden> wrote:
> >> >> >> >> >> >> >> > I don't see a directory ~ldm/decoders to contain the 
> >> >> >> >> >> >> >> > dc* programs from $OS_BIN.  /usr/local/ldm/decoders is 
> >> >> >> >> >> >> >> > in the ldm user's $PATH, so it's looking there for 
> >> >> >> >> >> >> >> > decoders but not finding them.  This explains why some 
> >> >> >> >> >> >> >> > raw data were written - these pattern actions are 
> >> >> >> >> >> >> >> > using a FILE command rather than PIPE to a decoder.
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > The solution is to copy all dc* programs from $OS_BIN 
> >> >> >> >> >> >> >> > to ~ldm/decoders, or to symlink the ~ldm/decoders 
> >> >> >> >> >> >> >> > directory to $OS_BIN.
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > Michael
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> Michael,
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> I took all the filters out of pqact.conf just so I 
> >> >> >> >> >> >> >> >> could be sure that
> >> >> >> >> >> >> >> >> the only calls I was making was to a GEMPAK needed 
> >> >> >> >> >> >> >> >> file.   I actually
> >> >> >> >> >> >> >> >> had one IDS call open yesterday..... bad form I 
> >> >> >> >> >> >> >> >> guess, but that didn't
> >> >> >> >> >> >> >> >> stop pqact.gempak from running.
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Here is the LDM environment:
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> [ldm@awipserver ~]$ env
> >> >> >> >> >> >> >> >> MANPATH=/usr/local/ldm:man:/usr/man
> >> >> >> >> >> >> >> >> HOSTNAME=awipserver.physics.umbc.edu
> >> >> >> >> >> >> >> >> TERM=xterm-color
> >> >> >> >> >> >> >> >> SHELL=/bin/bash
> >> >> >> >> >> >> >> >> HISTSIZE=1000
> >> >> >> >> >> >> >> >> SSH_CLIENT=130.85.163.143 49658 22
> >> >> >> >> >> >> >> >> SSH_TTY=/dev/pts/2
> >> >> >> >> >> >> >> >> USER=ldm
> >> >> >> >> >> >> >> >> LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35:
> >> >> >> >> >> >> >> >> MAIL=/var/spool/mail/ldm
> >> >> >> >> >> >> >> >> PATH=/usr/local/ldm/decoders:/usr/local/ldm/util:/usr/local/ldm:bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/ldm/bin
> >> >> >> >> >> >> >> >> INPUTRC=/etc/inputrc
> >> >> >> >> >> >> >> >> PWD=/usr/local/ldm
> >> >> >> >> >> >> >> >> LANG=en_US.UTF-8
> >> >> >> >> >> >> >> >> SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
> >> >> >> >> >> >> >> >> SHLVL=1
> >> >> >> >> >> >> >> >> HOME=/usr/local/ldm
> >> >> >> >> >> >> >> >> LOGNAME=ldm
> >> >> >> >> >> >> >> >> LDMHOME=/usr/local/ldm
> >> >> >> >> >> >> >> >> CVS_RSH=ssh
> >> >> >> >> >> >> >> >> SSH_CONNECTION=130.85.163.143 49658 130.85.163.219 22
> >> >> >> >> >> >> >> >> LESSOPEN=|/usr/bin/lesspipe.sh %s
> >> >> >> >> >> >> >> >> G_BROKEN_FILENAMES=1
> >> >> >> >> >> >> >> >> _=/bin/env
> >> >> >> >> >> >> >> >> [ldm@awipserver ~]$
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> And, no, "does /usr/local/ldm/data point to 
> >> >> >> >> >> >> >> >> /mnt/sbd/var/ldm?"   No,
> >> >> >> >> >> >> >> >> it is  /usr/local/ldm/data > /usr/local/ldm/var/data 
> >> >> >> >> >> >> >> >> ..... It is using
> >> >> >> >> >> >> >> >> the var as a symbolic link and that should be changed 
> >> >> >> >> >> >> >> >> so it explicitly
> >> >> >> >> >> >> >> >> points to the right level on /mnt/sdb....
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> So the symbolic link should be
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> ln -s /mnt/sdb/ldm/var/data       data
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> for the data symbolic link?
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> the parallel structure on /mnt/sdb should be?????
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> ldm
> >> >> >> >> >> >> >> >> var
> >> >> >> >> >> >> >> >> data    logs   queues?
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Here is the directory for /usr/local/ldm:
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 ldm  ldm    11 Nov 30 13:47 bin -> 
> >> >> >> >> >> >> >> >> runtime/bin
> >> >> >> >> >> >> >> >> -rw-rw-r-- 1 ldm  ldm   214 Dec  3 14:22 crontab
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 ldm  ldm    23 Nov 30 13:47 data -> 
> >> >> >> >> >> >> >> >> /usr/local/ldm/var/data
> >> >> >> >> >> >> >> >> drwxr-xr-x 2 ldm  ldm  4096 Nov 30 13:26 Desktop
> >> >> >> >> >> >> >> >> drwxrwxr-x 2 ldm  ldm  4096 Dec  5 09:42 etc
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 ldm  ldm    15 Nov 30 13:47 include -> 
> >> >> >> >> >> >> >> >> runtime/include
> >> >> >> >> >> >> >> >> drwxr-xr-x 7 ldm  ldm  4096 Nov 30 13:46 ldm-6.11.1
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 ldm  ldm    11 Nov 30 13:47 lib -> 
> >> >> >> >> >> >> >> >> runtime/lib
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 ldm  ldm    23 Nov 30 13:47 logs -> 
> >> >> >> >> >> >> >> >> /usr/local/ldm/var/logs
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 ldm  ldm    10 Dec  3 13:33 runtime -> 
> >> >> >> >> >> >> >> >> ldm-6.11.1
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 ldm  ldm    13 Nov 30 13:47 share -> 
> >> >> >> >> >> >> >> >> runtime/share
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 ldm  ldm    11 Nov 30 13:47 src -> 
> >> >> >> >> >> >> >> >> runtime/src
> >> >> >> >> >> >> >> >> lrwxrwxrwx 1 root root   12 Dec  3 13:45 var -> 
> >> >> >> >> >> >> >> >> /mnt/sdb/var
> >> >> >> >> >> >> >> >> -rw-rw-r-- 1 ldm  ldm    25 Dec  5 09:37 watch.txt
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> Ray
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> On Wed, Dec 5, 2012 at 2:20 PM, Unidata GEMPAK Support
> >> >> >> >> >> >> >> >> <address@hidden> wrote:
> >> >> >> >> >> >> >> >> > Hi Raymond,
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > Thanks for attaching the logs and environmental 
> >> >> >> >> >> >> >> >> > variable files.
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > The first thing noticed in ldmd.log is
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > Dec 05 14:35:36 awipserver pqact[19304] NOTE: 
> >> >> >> >> >> >> >> >> > Configuration-file "/usr/local/ldm/etc/pqact.conf" 
> >> >> >> >> >> >> >> >> > has no entries. You should probably not start this 
> >> >> >> >> >> >> >> >> > program instead.
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > Which suggests the pqact.conf isn't being taken 
> >> >> >> >> >> >> >> >> > correctly.  Even so, there are decoder entries in 
> >> >> >> >> >> >> >> >> > the log file such as:
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > Dec 05 14:35:36 awipserver pqact[19308] ERROR: 
> >> >> >> >> >> >> >> >> > [filel.c:1404] Couldn't execute decoder 
> >> >> >> >> >> >> >> >> > "decoders/dcnldn"
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > So I'm not entirely sure what the problem is, but I 
> >> >> >> >> >> >> >> >> > can guess that it's due to difference between data 
> >> >> >> >> >> >> >> >> > directories in the gempak and ldm users' 
> >> >> >> >> >> >> >> >> > environment.
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > What is 'env' os the user ldm, and does 
> >> >> >> >> >> >> >> >> > /usr/local/ldm/data point to /mnt/sbd/var/ldm?
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > -Michael
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> >> Michael,
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> Ok, I have LDM and GEMPAK running but not much is 
> >> >> >> >> >> >> >> >> >> getting decoded by
> >> >> >> >> >> >> >> >> >> pqact.gempak.   I suspect it is due to an 
> >> >> >> >> >> >> >> >> >> incorrect directory
> >> >> >> >> >> >> >> >> >> structure in the LDM directory.
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> What I've done:
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> 1) I have ldm and gempak as users on 
> >> >> >> >> >> >> >> >> >> awipsserver.physics.umbc.edu.
> >> >> >> >> >> >> >> >> >> ldm's home directory is /usr/local/ldm  (as 
> >> >> >> >> >> >> >> >> >> suggested in the ldm
> >> >> >> >> >> >> >> >> >> documentation).  gempak's home directory is 
> >> >> >> >> >> >> >> >> >> /home/gempak  (with other
> >> >> >> >> >> >> >> >> >> users)
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> 2)  If I run pqact.conf that comes with ldm, I can 
> >> >> >> >> >> >> >> >> >> pull feeds (see
> >> >> >> >> >> >> >> >> >> watch.txt attached) from idd.meteo.psu.edu and it 
> >> >> >> >> >> >> >> >> >> looks like the
> >> >> >> >> >> >> >> >> >> UNIDATA feed (and the UNIWISC) feeds work.
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> 3)  When I built ldm, I did not want the /var 
> >> >> >> >> >> >> >> >> >> directory on my main
> >> >> >> >> >> >> >> >> >> hard drive on the server, but I put it on a raid  
> >> >> >> >> >> >> >> >> >> (/mnt/sdb/var) and I
> >> >> >> >> >> >> >> >> >> symbolically linked /var and /data in ldm to point 
> >> >> >> >> >> >> >> >> >> to /mnt/sdb/var and
> >> >> >> >> >> >> >> >> >> /mnt/sdb/var/data).   That worked ok and the ldm 
> >> >> >> >> >> >> >> >> >> data was pushed to
> >> >> >> >> >> >> >> >> >> /mnt/sdb/var/data/surface/US.... for the demo 
> >> >> >> >> >> >> >> >> >> pqact.conf feeds from
> >> >> >> >> >> >> >> >> >> IDS.
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> 4) In GEMPAK, all built out ok (except for the /gf 
> >> >> >> >> >> >> >> >> >> bug that I sent
> >> >> >> >> >> >> >> >> >> previously) and GEMPAK runs fine.   I attach the 
> >> >> >> >> >> >> >> >> >> env for gempak.   I
> >> >> >> >> >> >> >> >> >> think the issue is here.   I left $GEMDATA as it 
> >> >> >> >> >> >> >> >> >> was in Gemenviron as
> >> >> >> >> >> >> >> >> >> it was built by the csh routine in GEMPAK.
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> setenv GEMDATA       /data/ldm/gempak
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> That seemed strange to me but it started putting 
> >> >> >> >> >> >> >> >> >> the gempak data in
> >> >> >> >> >> >> >> >> >> /usr/local/ldm/data/data/images/    etc....
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> I only got /images   /jason  and  /nwx  built in 
> >> >> >> >> >> >> >> >> >> that directory .
> >> >> >> >> >> >> >> >> >> /surface doesn't get decoded.    From the 
> >> >> >> >> >> >> >> >> >> gempak_env, you can see that
> >> >> >> >> >> >> >> >> >> it set up the /usr/local/ldm/data/data/gempak 
> >> >> >> >> >> >> >> >> >> structure.
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> I attach a zipped version of the ldmd.log file 
> >> >> >> >> >> >> >> >> >> with the errors.  It
> >> >> >> >> >> >> >> >> >> looks like this is not feed related but the 
> >> >> >> >> >> >> >> >> >> decoders are not all
> >> >> >> >> >> >> >> >> >> working.
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> 5) To make GEMPAK read from the right files,  I 
> >> >> >> >> >> >> >> >> >> had to change the
> >> >> >> >> >> >> >> >> >> above Gemenviron variable to be
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> setenv GEMDATA      /usr/local/ldm/data/data/gempak
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> and then GEMPAK could go and get the data that was 
> >> >> >> >> >> >> >> >> >> available (images
> >> >> >> >> >> >> >> >> >> mostly.... the GOES data is coming in ok.)
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> Suggestions on how to fix the Gemenviron file 
> >> >> >> >> >> >> >> >> >> (also attached)?
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> Ray
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> >> >> Raymond M. Hoff
> >> >> >> >> >> >> >> >> >> Professor of Physics
> >> >> >> >> >> >> >> >> >> Rm 426, Physics Dept.
> >> >> >> >> >> >> >> >> >> University of Maryland, Baltimore County
> >> >> >> >> >> >> >> >> >> 1000 Hilltop Circle
> >> >> >> >> >> >> >> >> >> Baltimore MD 21250
> >> >> >> >> >> >> >> >> >> p: 410-455-1943 f:410-455-1042
> >> >> >> >> >> >> >> >> >> e: address@hidden
> >> >> >> >> >> >> >> >> >> physics.umbc.edu/~hoff
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >> > Ticket Details
> >> >> >> >> >> >> >> >> > ===================
> >> >> >> >> >> >> >> >> > Ticket ID: XDH-337278
> >> >> >> >> >> >> >> >> > Department: Support GEMPAK
> >> >> >> >> >> >> >> >> > Priority: Normal
> >> >> >> >> >> >> >> >> > Status: Open
> >> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> >> Raymond M. Hoff
> >> >> >> >> >> >> >> >> Professor of Physics
> >> >> >> >> >> >> >> >> Rm 426, Physics Dept.
> >> >> >> >> >> >> >> >> University of Maryland, Baltimore County
> >> >> >> >> >> >> >> >> 1000 Hilltop Circle
> >> >> >> >> >> >> >> >> Baltimore MD 21250
> >> >> >> >> >> >> >> >> p: 410-455-1943 f:410-455-1042
> >> >> >> >> >> >> >> >> e: address@hidden
> >> >> >> >> >> >> >> >> physics.umbc.edu/~hoff
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >> > Ticket Details
> >> >> >> >> >> >> >> > ===================
> >> >> >> >> >> >> >> > Ticket ID: XDH-337278
> >> >> >> >> >> >> >> > Department: Support GEMPAK
> >> >> >> >> >> >> >> > Priority: Normal
> >> >> >> >> >> >> >> > Status: Open
> >> >> >> >> >> >> >> >
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> Raymond M. Hoff
> >> >> >> >> >> >> >> Professor of Physics
> >> >> >> >> >> >> >> Rm 426, Physics Dept.
> >> >> >> >> >> >> >> University of Maryland, Baltimore County
> >> >> >> >> >> >> >> 1000 Hilltop Circle
> >> >> >> >> >> >> >> Baltimore MD 21250
> >> >> >> >> >> >> >> p: 410-455-1943 f:410-455-1042
> >> >> >> >> >> >> >> e: address@hidden
> >> >> >> >> >> >> >> physics.umbc.edu/~hoff
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > Ticket Details
> >> >> >> >> >> >> > ===================
> >> >> >> >> >> >> > Ticket ID: XDH-337278
> >> >> >> >> >> >> > Department: Support GEMPAK
> >> >> >> >> >> >> > Priority: Normal
> >> >> >> >> >> >> > Status: Open
> >> >> >> >> >> >> >
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> --
> >> >> >> >> >> >> Raymond M. Hoff
> >> >> >> >> >> >> Professor of Physics
> >> >> >> >> >> >> Rm 426, Physics Dept.
> >> >> >> >> >> >> University of Maryland, Baltimore County
> >> >> >> >> >> >> 1000 Hilltop Circle
> >> >> >> >> >> >> Baltimore MD 21250
> >> >> >> >> >> >> p: 410-455-1943 f:410-455-1042
> >> >> >> >> >> >> e: address@hidden
> >> >> >> >> >> >> physics.umbc.edu/~hoff
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > Ticket Details
> >> >> >> >> >> > ===================
> >> >> >> >> >> > Ticket ID: XDH-337278
> >> >> >> >> >> > Department: Support GEMPAK
> >> >> >> >> >> > Priority: Normal
> >> >> >> >> >> > Status: Open
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> Raymond M. Hoff
> >> >> >> >> >> Professor of Physics
> >> >> >> >> >> Rm 426, Physics Dept.
> >> >> >> >> >> University of Maryland, Baltimore County
> >> >> >> >> >> 1000 Hilltop Circle
> >> >> >> >> >> Baltimore MD 21250
> >> >> >> >> >> p: 410-455-1943 f:410-455-1042
> >> >> >> >> >> e: address@hidden
> >> >> >> >> >> physics.umbc.edu/~hoff
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > Ticket Details
> >> >> >> >> > ===================
> >> >> >> >> > Ticket ID: VFW-525515
> >> >> >> >> > Department: Support GEMPAK
> >> >> >> >> > Priority: Normal
> >> >> >> >> > Status: Open
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Raymond M. Hoff
> >> >> >> >> Professor of Physics
> >> >> >> >> Rm 426, Physics Dept.
> >> >> >> >> University of Maryland, Baltimore County
> >> >> >> >> 1000 Hilltop Circle
> >> >> >> >> Baltimore MD 21250
> >> >> >> >> p: 410-455-1943 f:410-455-1042
> >> >> >> >> e: address@hidden
> >> >> >> >> physics.umbc.edu/~hoff
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> > Ticket Details
> >> >> >> > ===================
> >> >> >> > Ticket ID: VFW-525515
> >> >> >> > Department: Support GEMPAK
> >> >> >> > Priority: Normal
> >> >> >> > Status: Open
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Raymond M. Hoff
> >> >> >> Professor of Physics
> >> >> >> Rm 426, Physics Dept.
> >> >> >> University of Maryland, Baltimore County
> >> >> >> 1000 Hilltop Circle
> >> >> >> Baltimore MD 21250
> >> >> >> p: 410-455-1943 f:410-455-1042
> >> >> >> e: address@hidden
> >> >> >> physics.umbc.edu/~hoff
> >> >> >>
> >> >> >>
> >> >> >
> >> >> > Ticket Details
> >> >> > ===================
> >> >> > Ticket ID: VFW-525515
> >> >> > Department: Support GEMPAK
> >> >> > Priority: Normal
> >> >> > Status: Open
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Raymond M. Hoff
> >> >> Professor of Physics
> >> >> Rm 426, Physics Dept.
> >> >> University of Maryland, Baltimore County
> >> >> 1000 Hilltop Circle
> >> >> Baltimore MD 21250
> >> >> p: 410-455-1943 f:410-455-1042
> >> >> e: address@hidden
> >> >> physics.umbc.edu/~hoff
> >> >>
> >> >>
> >> >
> >> >
> >> > Ticket Details
> >> > ===================
> >> > Ticket ID: VFW-525515
> >> > Department: Support GEMPAK
> >> > Priority: Normal
> >> > Status: Open
> >> >
> >>
> >>
> >>
> >> --
> >> Raymond M. Hoff
> >> Professor of Physics
> >> Rm 426, Physics Dept.
> >> University of Maryland, Baltimore County
> >> 1000 Hilltop Circle
> >> Baltimore MD 21250
> >> p: 410-455-1943 f:410-455-1042
> >> e: address@hidden
> >> physics.umbc.edu/~hoff
> >>
> >>
> >
> > Ticket Details
> > ===================
> > Ticket ID: VFW-525515
> > Department: Support GEMPAK
> > Priority: Normal
> > Status: Open
> >
> 
> 
> 
> --
> Raymond M. Hoff
> Professor of Physics
> Rm 426, Physics Dept.
> University of Maryland, Baltimore County
> 1000 Hilltop Circle
> Baltimore MD 21250
> p: 410-455-1943 f:410-455-1042
> e: address@hidden
> physics.umbc.edu/~hoff
> 
> 

Ticket Details
===================
Ticket ID: VFW-525515
Department: Support GEMPAK
Priority: Normal
Status: Open